It's Actors All The Way Down

This description of the Actor Model is intended to build intuition about how the model works using reasonably precise terms. However, it is not a formal mathematical description. We are focusing on the so-called “classic” model [1], which is treated with much more formality in earlier literature [2] [3].

Overview

A configuration is a set of actors and a list of events.

C = < { actor, ... }, [ event, ... ] >

An event is a target (an actor address) and message.

< target, message >

An actor is a mapping from address (ocap identity) to behavior.

{ address: behavior, ... }

A behavior is a function from event to effect.

event → effect

An effect is a set of new actors, a list of new events, and a new behavior.

< { actor′, ... }, [ event′, ... ], behavior′ >

A semantic step is defined by a transition function from configuration to configuration.

C → C′

The transition function takes an event from the event list (selected arbitrarily by a “fair” oracle to avoid starvation), and applies the behavior of the target to the event, producing an effect. The effect defines the updated configuration by removing the processed event, adding the new actors, appending the new events, and updating the behavior associated with the target actor.

Configuration

A configuration represents a complete and coherent snapshot of the state of an actor system.

C = < { address: behavior, ... }, [ < target, message >, ... ] >

The pending event-list represents the remaining work to be done. If the event-list is empty, the system is quiescent.

Event

An event represents a request for work to be done. Events in the configuration’s event-list represent messages in transit. Events are not visible to any actor until they are delivered to the target actor.

Actor

An actor is an isolated entity that reacts to events by performing computation and maintaining its own private state. Immutable data may be shared between actors, since such sharing can’t cause interference between actors.

Behavior

A behavior encapsulates the state of an actor and determines the effects (if any) caused by the reception of an event. An actor’s state is updated by defining a new behavior to become.

Effect

An effect represents a collection of potential updates to a configuration. There are three kinds of effects:

• Create a new actor
• Send a new message
• Become a new behavior

A new actor is created with an initial behavior. The address of the new actor is determined by the system, and made available to the creator. The address is an object-capability which represents the authority to send messages to the designated actor.

Sending a message creates a new event designating a target actor and message contents. Each event is a unique entity, even if the target and message are the same as another event. Events are immutable and may contains actor addresses (among other data).

An actor may designate a new behavior to become, which may change the way it will react to subsequent events. If no new behavior is provided, the current behavior will be used for subsequent events. An effect may include multiple new actors and/or multiple message-events, but only one become.

Transition Step

A transition step from one configuration to the next corresponds to the delivery and processing of a single event. All message-passing is via one-way asynchronous events. Any message-event may be arbitrarily delayed, but must be delivered eventually.

A message is delivered by removing it from the event-list and applying the behavior of the target to the event. This produces an effect describing the desired updates to the configuration. The effect is applied to configuration atomically. Note that the only possible actor-state mutation is replacement of the target’s behavior.

The semantic model processes a single event (to a single actor) at a time. Applying the resulting effect causes a transition from one configuration to the next. Implementations are free to provide more concurrency, as long as the results are equivalent to a sequence of atomic transactions.

For example, events targeting different actors may be processed concurrently because their processing cannot cause interference or mutations visible between actors. Changes to the configuration are only observable indirectly, via delivery of subsequent asynchronous messages.

References

[1]

Joeri De Koster, Tom Van Cutsem, and Wolfgang De Meuter. 43 years of actors: a taxonomy of actor models and their key properties. Proceedings of the 6th International Workshop on Programming Based on Actors, Agents, and Decentralized Control (AGERE 2016). ACM, 2016.

[2]

Gul Agha, Ian Mason, Scott Smith, and Carolyn Talcott. Towards a Theory of Actor Computation. Proceedings of the Third International Conference on Concurrency Theory pp.565-579. August 1992.

[3]

Gul Agha, Ian Mason, Scott Smith, and Carolyn Talcott. A Foundation for Actor Computation. Journal of Functional Programming, Vol. 7, No. 1, January 1997.