A Glossary of Actor Terms

Since Gul Agha's actor glossary [1] is very useful, we include here some of his descriptions and some additions or changes (marked with (*)).

Actor termbrief description
acquaintanceAn actor $\alpha$ is an acquaintance of an actor $\beta$ if $\beta$ knows the mail address of $\alpha$.
actorA computational agent which has an mail address and a behavior. Actors communicate by message-passing and carry out their actions concurrently.
asynchronous communicationCommunication is considered to be asynchronous when the sender does not have to wait for the recipient to be ready to accept a communication before the sender can send the communication.
behavior (*)The behavior of an actor maps the incoming communication to a three tuple of messages sent, new actors created, and the replacement behavior.
behaviour (*)"A behavior encapsulates common behavioral patterns." Armstrong [2] The Erlang world has a more complex view of behaviors. Such more complex behaviors can be realized with a message protocol.
communicationThe only mechanism by which actors may affect each other's behavior. The content of a message sent by an actor is called a communication.
concurrencyThe potentially parallel execution of actions without a determinate predefined sequence for their actions.
customerA request communication contains the mail address of an actor called the customer to which a reply to the request is to be sent. Customers are dynamically created to carry out the rest of the computation, so that an actor sending a request to another actor can begin processing the next incoming communication without waiting for the subcomputations of the previous communication to complete.
eventIn the actor model, an event is the acceptance of a communication by an actor. In response to accepting a communication, an actor creates other actors, sends communications and specifies a replacement behavior; in an event based semantics these actions are considered a part of the event.
external actorAn actor which is external to a configuration but whose mail address is known to some actor within the configuration.
futureA future is an actor representing the value of a computation in progress. Futures can speed up computation since they allow subcomputations using references to a value to proceed concurrently with the evaluation of an expression to compute the value. Communications sent to a future are queued until the value has been determined.
mail addressA virtual location by which an actor may be accessed. Each actor has a unique mail address which is invariant, although the behavior of an actor may change over time.
mail queueThe queue of incoming communications sent to a given actor. The mail queue represents the arrival order of communications and provides the means to buffer communications until they are processed by the target actor.
protocol (*)An actor follows a protocol if it – when receiving certain messages – executes predefined behaviors other than its current behavior. This is used to implement more complex behaviors and goes beyond the classical model.
receptionistAn actor to whom communications may be sent from outside the configuration to which it belongs. The set of receptionists evolves dynamically as the mail addresses of various actors may be communicated to actors outside the system.
replacement behaviorA behavior specified by an actor processing a communication which is used to process the next communication in the mail queue of the actor.
replyA communication sent in response to a request (see also customers).
requestA communication asking for a response to be sent to a customer contained in the request.
synchronous communicationCommunication between two actors requiring the sender to wait until the recipient acknowledges or otherwise responds to the communication before continuing with further processing. Synchronous communication in actors is implemented using customers.
  • 1Gul Agha 1986. Actors. a model of concurrent computation in distributed systems, MIT; Appendix B
  • 2Joe Armstrong 2014. Programming Erlang, 2nd Ed., Software for a Concurrent World, Pragmatic Programmers; p. 361