DEV Community

Discussion on: Explain Actor concurrency model like I'm five

Collapse
 
centur profile image
Alexey Shcherbak

One of the best abstractions for actors I discovered for myself are "real world" entities. So let's communicate actors concept to 5yo.
Imagine that you're programming real world. You have humans - human is our actor type. They all kind of the same - 2 hands, 2 legs, body and head, so they are the same type, but each human is very unique, and has an absolutely unique name (which is actor ID - "DNA sequence").
So now you, as a world operator (developer), want to perform some work and make this world a bit better place - you start to mail some work tasks to your actors.

This is the only way you can ask humans to do something. Each mail arrives into input mailbox from which it's picked by our human instance. Human, when picks a mail (only one of many of them), process it sequentially, working through the mailbox queue one by one. This approach eliminates many situations when human has 2 or more mails opened simultaneously and the tasks are contradicting each other (or compete for a shared resource, say both want to use actor's right hand).

You can have different types of tasks - for some of them you may want to ask specific human and receive report back from him - your mail would contain a recipient name and return address where to send back report. For some tasks - you're not fast about who will do the work, you just want it to be done, eventually - so you can create a new human for every task and assign him that unique job, and this ensures that your mail with task will not be delayed by any other pending mails in this particular human mailbox. Although be mindful - creation of human actor is "cheap", but not "free".

Also humans are not always work well - they may fall sick or been struck by lightning, so they have to report to their supervisor that they actually can't complete their current task (or actors can die w\o reply so there will be a timeout error @supervisor level). Then supervisor must decide what to do in this case - communicate back to operator that "this task can't be completed" or try to re-create human and try to task him with the same task again.

Now, all humans work independently and they really don't block each other out of CPU resource, so when they have to asynchronously wait for some computation to complete - they allow others to take their turns on CPU and process their tasks, so they are cooperating together for higher concurrency and better resource utilisation.

Humans can interact with other humans and with actors of other types (cars, birds, planes) using the same mailing mechanism.

Normally before sending a message to some actor, operator needs to ensure that actor with such name\ID was created before and operator knows it's name (holds a reference to an instance). There is an extension of actor model, called "virtual actors" (such as in Orleans and Orbit frameworks). They are like "always-exist humans" - operator simply sends a message - and such actor instance automatically created (or if it's already activated - existing instance is used) and task is placed in it's input mailbox.

Using actors of different types and their interactions, developer can easily build and operate very complex programming workflows, with a high throughput because of cooperating concurrency and very few concurrency-related problems (as each actor can process only one task at a time, eliminating many multi-threading problems around shared resource).