Link Details

Link 629797 thumbnail
User 878467 avatar

By twr@chariotsolutions.com
via chariotsolutions.blogspot.com
Published: Jul 07 2011 / 04:42

I spent a fair amount of time developing actor-based systems recently, specifically with the Scala Actor library. Regardless of whether you are implementing actors with the Scala library, Akka, Lift or Scalaz, some basic gotchas can present themselves until you get a feel for what you're doing. Here are some of them that I've learned the hard way.
  • 8
  • 0
  • 1794
  • 6

Comments

Add your comment
User 393686 avatar

RawThinkTank replied ago:

0 votes Vote down Vote up Reply

He forgot to mention how to spawn a thread on a particular core for an actor.

User 759731 avatar

shinolajla replied ago:

0 votes Vote down Vote up Reply

@RawThinkTank FYI, I'm the author of the post, just wanted to respond to your point. I assume you're using thread-based actors when spawning for a particular core. Can you share a use case for when you would want to do this? Is it to for cache coherence?

Note that I've only used event-based actors in production with a shared thread pool.

User 393686 avatar

RawThinkTank replied ago:

-1 votes Vote down Vote up Reply

i dont know if its even possible, but if its not then the writing is clear on the walls that days of JVM are numbered.

its obvious that people are gona move to platforms that allow them to write multicore concurrent programs instead of just paralleling serial ones and pseudo concurrency that has no control over cores.

User 279247 avatar

bclapper replied ago:

0 votes Vote down Vote up Reply

Right. Erlang isn't popular at all. Scala's increasing adoption on the JVM is clearly an anomaly. Microsoft's rolling out F# is laughable and stupid.

Instead of bloviating pointless responses like this, why not write a well-researched, well-written blog article of your own, one that attempts to set forth your position logically and coherently?

Assuming, of course, that you're capable of doing so. I'm dubious...

User 279247 avatar

bclapper replied ago:

0 votes Vote down Vote up Reply

There are ways to dedicate a thread to an actor. But as for dedicating an actor or a thread to a core--are you really sure you can do a better job of processing and thread scheduling than the operating system?

If so, I await your blog post(s).

User 279247 avatar

bclapper replied ago:

0 votes Vote down Vote up Reply

There are ways to dedicate a thread to an actor. But as for dedicating an actor or a thread to a core--are you really sure you can do a better job of processing and thread scheduling than the operating system?

If so, I await your blog post(s).

User 759731 avatar

shinolajla replied ago:

0 votes Vote down Vote up Reply

In reviewing the LMAX architecture, I think I'm getting a fundamental grip on where you're going with this. It's worth noting that LMAX built their system on the JVM with highly-tuned Java, though.

However, controlling cores comes with a price. LMAX's architecture works because they have a balanced flow of operations that a single core can work on. If your flow is unbalanced, you need the ability to switch contexts via waits or ForkJoin. Or possibly actors.

I guess my point is that you have to choose your architecture by the needs of your system. Actors are a composable abstraction for concurrency that work well in systems with certain performance characteristics, even heavy load. For extreme cases (like LMAX), they're not a good fit.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Voters For This Link (8)



Voters Against This Link (0)



    Java Performance Optimization
    Written by: Pierre-Hugues Charbonneau
    Featured Refcardz: Top Refcardz:
    1. Design Patterns
    2. OO JS
    3. Cont. Delivery
    4. Java EE7
    5. HTML5 Mobile
    1. Node.js
    2. Debugging JavaScript
    3. OO JS
    4. JSON
    5. Ajax