Introduction to Actors

Actors

We have mentioned several times the existence of an actor, the most basic feature and one of the main building blocks of Akka.NET. An actor encapsulates an object’s behavior and state, and communicates with other actors by exchanging messages. Every instance of an actor has its own MailBox where the messages will be enqueued and successively processed by the actor, one by one, respecting the order of messages.

By using actors, we have simple and high-level abstractions for concurrency and parallelism. This is due to the fact that every time an actor processes a message, this might happen on another thread.

Tip: To better visualize the idea of an actor, let’s think of an actor as a real person. This person can distribute (delegate) the work to other people, or simply fail at processing certain messages.

Actors are built and organized around a hierarchical structure in order to split the tasks into smaller and more manageable pieces. If we think about it, this is very similar to object-oriented programming where we have classes and functions in order to split or organize some larger logic into a smaller subset of building blocks. This also implies that actors are able to create and supervise subactors and control their lifetimes: creation and termination. This also implies that every actor has only one supervisor.

Figure 5: Actor’s communication by message passing

Actor lifecycle

Every actor has its own lifecycle, which exists in the moment when the actor is created, is running, and is terminated. Even though creating a new instance of an actor is relatively cheap in terms of memory and processing, a proper handling of the life of an actor should be planned.

ActorSystem

One of the ActorSystem responsibilities is to manage the resources in order to run the actors. An ActorSystem is a hierarchical group of actors that share common configuration, for example, dispatchers, deployments, thread pooling, remote capabilities, and addresses. An actor cannot exist outside the ActorSystem; therefore, we can also say that an ActorSystem is a container or a host of actors.

An ActorSystem is not cheap to create, it’s typically created only once per application, even though multiple systems can run in the same application on top of .NET runtime. Once it’s up and running, it will usually be there for the whole lifetime of the application, or at least until it’s not needed (terminated). In that case, the different actor systems won’t have anything in common and would live in separate memory spaces, threads, etc.

Figure 6: Multiple actor systems within one application

An ActorSystem handles the following aspects:

• Creates and allocates threads, so that the actors can use the underlying threads.
• Hosts the configuration.

Actor reference

As stated previously, an actor has a state, behavior, mailbox, child actors, and supervision strategy. All of this is encapsulated behind an actor reference.

In an actor system, actors are referenced by actor references, which are like pointers to an instance of an actor. The actor reference enables actors to have a reference to another actor (send messages); however, this is unrelated to the actual state (lifecycle) of the actor itself. Removing a reference to an actor doesn’t “destroy” that actor, and vice versa.

The actor reference, on the other hand, makes possible the so-called location transparency of actors, which means that an actor can be deployed on a remote system, but from the actor-reference perspective (client calling the actor), nothing changes in the programming model.

Phone calls are a good example to explain the location transparency: We have the phone number (of a person), so sending an SMS or placing a phone call is always possible, where ever the other person is located. 

An actor reference can be passed around as a variable. An actor through actor references always has the ability to access the child actors, self, sender, and its parent actor.