Interest in Actor-based concurrency on the JVM has been growing, but few developers realize the wealth of choices already available for Actor programming. In the concluding segment of his JavaWorld series, Understanding actor concurrency, Part 2: Actors on the JVM, Alex Miller introduces six possible approaches to Actor-based JVM concurrency.
The most mature solution, according Miller, is Scala's Actors library, if developing in the Scala language is an option:
The Scala support for actors is quite strong, building firmly on the Erlang model. Writing actors code is a natural part of writing Scala code, and the Scala library has full support not just for actor definition, pattern matching, and flexible message send, but also for many of the Erlang-style error-handling primitives. An implementation of the Erlang OTP Supervisor functionality and a distributed version using Terracotta also exist.
Miller develops a simple example for Scala Actors, illustrating the key Scala constructs used to support Actor programming:
Scala is a hybrid language that takes cues from both the object-oriented and functional programming traditions. It is designed to be extensible and to grow into new language features as needed. The language itself is built on a small core of principles, but it has a much larger perceived surface area thanks to these "scalable" language capabilities.
In fact, the Scala actors implementation is provided as part of the Scala standard library ... not as part of the language. It replicates much of the Erlang actor model. The fact that this is possible to do well as a library is a testament to Scala's flexibility.
Scala actors support all of the key concepts from Erlang. Actors are defined as a trait in the Scala standard library. In Scala, a trait is a set of method and field definitions that can be mixed into other classes. This is similar to providing an abstract superclass in Java but more flexible, particularly in comparison to multiple inheritance.
Miller describes the various Scala actor operators, such as ! for asynchronous message sending, !? for synchronous messages, and !! for Futures.
In addition to Scala Actors, Miller also describes Groovy's GParallizer library, as well as Kilim, ActorFoundry, Actors Guild, and Jetlang.
Regarding the last four Java libraries, Miller writes that:
All of them have a fundamental obstacle to overcome. Scala and Groovy can create lightweight actors by relying on scheduling over a thread pool of actors defined by partial functions or closures. In Java, these techniques don't exist as part of the language, so most of the Java actor libraries rely on bytecode modification either at compile time or runtime.
What is your favorite approach to Actor-programming on the JVM?
I found this phrase somewhere on the Internet: "The Actor Model solves concurrent programming problems simiply by not allowing any sharing of resources. Instead, one process or actor in the system is responsible for managing a resource."
This made me think whether the actor that manages the resources really needs to have to run in its own thread. I mean if it where thread-less still no deadlocks or race conditions could occur, because everything is executed sequentially and only "atomic" operations are executed such as add, remove, etc. But I'm not sure whether this is really correct. Also, the actor requesting data from the shared resource would have to pay for the CPU time to lookup the resource which is only fair.
Thanks for any body being able to shed some light on this.