What is the Actor Model?
Actor Model is a conceptual model of concurrent computation originated in 1973. In the Actor Model, an actor is a fundamental unit of computation and everything is an actor.
The only allowed operations for an actor are:
- to create another actor,
- to send a message
- or to designate how to handle the next message
First two operations are quite easy to understand. Let’s focus on the last one. An actor can hold its own private state and it can decide how to process the next message based on that state. Let’s imagine an actor that stores a total balance of our account. If our actor receives a message with a new transaction, it updates its state by adding the new amount to the already calculated total balance which means that for the next message the state of the actor will be different.
Properties of the actors
Actors are lightweight and it is easy to create thousands or even millions of them as they require fewer resources than threads.
Let’s have a look at the actors in more details. Actors are isolated from each other and they do not share memory. They have a state, but the only way to change it is by receiving a message. Every actor has its own mailbox, which is similar to a message queue. Messages are stored in actors’ mailboxes until they are processed. Actors, after created, are waiting for messages to arrive. Actors can communicate with each other only through messages. Messages are sent to actors’ mailboxes and processed in FIFO (first in, first out) order. Messages are simple, immutable data structures that can be easily sent over the network.
Conceptually an actor can handle only 1 message at a time. Actors are decoupled, they work asynchronously and they don’t need to wait for a response from another actor.
Addresses
Actors have addresses, so it’s possible for an actor to send a message to another actor by knowing its address. An actor can only communicate with actors whose addresses it has. An actor has addresses of the actors it has itself created and it can obtain other addresses from a message it receives. One actor can have many addresses. We need to remember that address is not equal to identity, so it doesn’t mean that two actors with the same identity have the same address.
Actors can run locally or remotely on another machine. It is completely transparent for the system as actors communicate through addresses which can be local or remote.
Fault tolerance
Now, let’s look at the fault tolerance. In the Actor Model, actors can supervise other actors. An actor can supervise the actors it creates and can decide what to do in case of failure. A supervisor can, for example, restart a supervised actor or redirect messages to another actor. It leads us to self-healing systems.
Pros and cons
Let’s have a look at the pros and cons of the Actor Model.
Pros | Cons |
---|---|
easy to scale | actors are susceptible to deadlocks |
fault tolerance | overflowing mailboxes |
geographical distribution | |
not sharing state |
Implementations of the Actor Model
We need to remember that the Actor Model is only a conceptual model and a lot of properties of your system depends on the chosen implementation. The best-known implementations of the Actor Model are Akka (Scala and Java) and Elixir (Erlang).
Akka ► https://akka.io
Elixir ► https://elixir-lang.org
Extras
If you want to learn more about the Actor Model please check this great talk by Carl Hewitt
If you want to learn more about different concurrency models including the Actor Model, I recommend the following book.
2 thoughts on “Actor Model Explained”
I think you forgot about erlang, and may be should have explain that actors are most about systems.
And also make the reader aware that actors is also very low level form of concurrency.
my 2 cents
keep up the good work 🙂
> The best-known implementations of the Actor Model are Akka (Scala and Java) and Elixir (Erlang).
The phrasing is a bit odd i think. I dont think Elixir isn’t an implementation of Erlang. From the Elixir site:
> Elixir leverages the Erlang VM,
I belive the Erlang VM is called the BEAM.
> BEAM is the virtual machine at the core of the Erlang Open Telecom Platform (OTP).[1] BEAM is part of the Erlang Run-Time System (ERTS), which compiles Erlang and Elixir source code into bytecode, which is then executed on the BEAM.[2][3] BEAM bytecode files have the .beam file extension.[4]
So it would be better to maybe say Elixer and Erlang (BEAM).