How are akka actors implemented on underlying threads?

Question

Given an execution context and a thread pool, how are akka/scala actors scheduled/implemented on that?

Answer 1

You can find relevant information in the akka documentation which is pretty complete as far as thing goes.

Essentially you can select/define dispatchers and assign actors to them through configuration (via files or code).

Each dispatcher implementation is then based on some sort of executor.

Answer 2

I was confused about this topic for a long time. I assumed that there is some relation between threads and actors. For each actor, there is a thread that hosts it, so I was thinking. Probably there are several actors for each thread that work in cooperative multitasking mode.

Documentation is focused on usage and covers internal architecture lightly. You just should extend the Actor class and you would get a working actor. So I tried to guess how can this be done and imagined that each Actor has life-cycle, something like wait asynchronously for a message queue, then process message and then go to start.

That was a totally false assumption. Although the documentation says "actor life-cycle" it does not mean Actor life-cycle. Actor mentioned is a conception rather than an actual object implementing the Actor class. The object resides passively in the java heap.

To breathe life into the conception, coordinated work involving a bunch of real workers is needed. And the heart of it is a dispatcher. It holds all actors, threads, and messages. And when the resources become available and there are messages available for processing the dispatcher activates. It takes an appropriate Actor object, wraps its receive method in runnable, and passes it to a spare thread. So there is no life-cycle for the object only occasional method calls from the actor system.

When you think of it, it makes much more sense than the scheme I assumed earlier. But it was hard for me to deduce it from available documentation. It was written by seasoned concurrency programmers. The distinguish holding the actor class from actor conception behind it. They know that dispatcher for an actor system is like a task scheduler for an OS. So they quickly get to the point and describe various flavors and realization of the conception assumed to be familiar to everyone.

But that is not so easy for a newbie. He has no acquaintance of the dispatcher pattern in the actor systems context. I tried to google "dispatcher pattern" and it showed definitions non-relevant to the actor system.

I've found easily double dispatch, multi-dispatch, and other OOP topics. I've found something similar to Akka's routers message dispatcher. There is probably a decent description for actor message dispatchers but it not so easy to find.

I hope I've cleared the misunderstanding.

Answer 3

On 'I was looking into something more like say you are given a thread pool of 10 threads and 50 actors spun off of it, how are so many actors handled by a batch of 10 threads?'

The exact behavior depends on the dispatcher and configuration. However, most dispatchers do basically something like this:

• Select an actor which has a non-empty mailbox
• That 'actor' is then dispatched to run on the executor
• Where messages are dequed and processed.
  • When possible, a few messages are dequed and processed one after another
  • After processing some messages (or none left), another actor is picked, to prevent starvation. (throughput parameter)
• Rise and repeat