By Vaclav Pech
The GPars project makes concurrency easily accessible and safe to use on the JVM. In this article. I’ll focus on the actor model part of GPars. We’ll experiment with the various types of actors that GPars provides and see their typical usages. All the project‘s functionality is available from Java and from Groovy, with which GPars is most often associated.

Introduction to Actors
The concept of actors as an approach to organizing concurrent activities has recently gained new popularity (thanks to the Scala, Erlang, and other programming languages). Actors provide a programming model that gives stronger guarantees about concurrent code when compared with the traditional shared-memory-based abstraction. Actors are essentially well encapsulated active objects, which can only communicate by sending one another immutable messages asynchronously. Whatever state an actor holds internally, it cannot be accessed from outside the actor except by sending a message to the actor and receiving its reply.

Because actors handle incoming messages asynchronously, they themselves need to be active. One way to make an object active is to dedicate a system thread to it. With actors, however, you frequently need to scale beyond the number of threads available on the system. That’s why actor implementations usually share threads among actors. If an actor has no work to do, it doesn’t consume system threads.

Full Story