Scala's Actors library, part of the standard Scala distribution, is a key attraction for developers desiring to learn Scala. Originally an implementation of the Actor-based concurrency in Erlang, the Scala Actors library enables developers to use the Actor concurrency model on the JVM in an idiomatic fashion. With the advent of multi-core processors, Scala's Actors library has become an important tool for scaling concurrent system.
One of the benefits of Scala's Actors library is that it takes advantage of Scala constructs to provide very close integration with the language: Using the Actors library feels as if Scala had native language support for Actors. While that simplicity is welcome by users of the library, it comes at the expense of some implementation complexity.
In trying to adapt the library to his parallel XML-processing framework, Erik Engbrecht found that grasping the library's internals required considerable effort. In particular, elements of the library implementation dealing with an actor's state are buried in fairly complex code, according to Engbrecht, who writes about the experience in Refactoring Scala Actors:
The external API for actors, particularly the documented part, is pretty clean and flexible. However internally, at least to a new set of eyes, there is a lot of spaghetti ..., oddly named variables and methods, and over a dozen mutable variables on the Actor trait that must all be correctly set in the right combination in order for the actor to work - and completely lacking any sort of structured means of manipulating them...
In my opinion the actors library is in desperate need of being refactored into something that encapsulates its state better and makes it much more explicit so you do not need to be an advanced adept to figure out what is happening inside the library. So I decided to do that refactoring and see where it lead me...
Reducing the statefulness of the actor, and more importantly making the primary state explicit instead of implicit, makes the code much easier to both debug and extend. In working with actors, I found that it's relatively common to have an actor just seem to stop. It could be because it's waiting for a message, it could be because it's stuck in a loop, it could be any number of things. Without explicit state, it's very difficult to tell exactly what's happening with an actor. With explicit state, it's right there in your debugger...
Engrecht reports on having made significant inroads into refactoring the Scala Actors library, and also provides a few benchmarks comparing the performance of his codebase to that of the original library.
What do you think of Scala's Actor's library from a user's perspective? If you've tried it already, did you find it easy to use? What are your Scala Actors pain points?
I've wanting to get my head around Actors now for a while but I'm not confident I fully understand the model. I was looking at the Actor class trying to get a better understanding of what Erik is doing.
I ended up in document by Martin Odersky and Pillip Heller where they basically say (feel free to correct me if I get this wrong) that actors allow for event-based programming without inversion of control.
I'm having a tough time with that. I guess it's just that it seems to me that all the actor is doing is hiding the event model under a thin façade. If that's what it's doing but is the distinction that simple? I feel like I am missing something.
I thought that was what Actors is all about. Parallell message passing with immutable data, except for within an actor where messages are handled serially.
> I'm having a tough time with that. I guess it's just that > it seems to me that all the actor is doing is hiding the > event model under a thin façade. If that's what it's > doing but is the distinction that simple? I feel like I > am missing something.
James - You're familiar with the pattern of having a thread-safe FIFO queue in front of a worker thread, where multiple producer threads put objects on the queue and the single worker/consumer thread processes them, right?
Event based actor basically implement that pattern, only instead of the thread sitting idle when there's nothing in the queue, the actor frees the thread so it can be used for other computation.
I've found it easier to think of this in terms of memory. I've read that a minimal Java thread consumes ~44kb worth of memory. An idle event-based actor is probably in the hundreds of bytes as long as it's not carrying a lot of other state. So you can have millions of idle actors because they cost very little to keep, but threads are a different matter.
As for the IoC argument, I'm not quite sure I buy it, but let me pretend and take a shot.
With actors there isn't a container in which the actors execute, and you have a lot of control over how it internally executes (assuming you grok the internals...). There's a lot of sphaghetti in the current implementation that makes this very hard and even impossible, but the underlying ideas are really quite extensible.
It doesn't exist today, but I think in the relatively near future Scala Actor's are really going to be much more a set of loosely coupled components that you can use in their default configuration or mix, match, and replace according to your needs.
> James - You're familiar with the pattern of having a > thread-safe FIFO queue in front of a worker thread, where > multiple producer threads put objects on the queue and the > single worker/consumer thread processes them, right? > > Event based actor basically implement that pattern, only > instead of the thread sitting idle when there's nothing in > the queue, the actor frees the thread so it can be used > for other computation.
This is basically my understanding.
In order to get good results with Actors, you pretty much have to have everything in the system running as an Actor, right? Otherwise you'd have a lot of blocking, right?
I'm doing some Java work lately where I'm trying to move a desktop app to an event based model. I feel that I'm going towards a pseudo-Actor model. Given that, it seems like a good idea to make sure I don't misunderstand that model.
It looks like you are doing some good stuff. Thanks for the response.
Previous Topic
