2.6 You've got mail: indeterminacy and the role of the arbiter

Although the actor model doesn't prescribe a mechanism for reliable message delivery, it acknowledges that many messages may be sent to a single actor in quick succession. Rapidly arriving messages could result in a sort of denial-of-service for the actor, rendering the actor incapable of processing the incoming message flow. To alleviate that problem, the actor model requires that a special object be provided by each actor for the purpose of receiving messages and holding those messages until the actor is able to process them. Such an arbiter is often called a mailbox, since it provides a function similar to, say, an email account: messages can arrive in the mailbox at any time and will be held there until the recipient is ready to process them.

Email clients give you complete freedom in choosing the order in which you read new messages. In a similar way, an actor's mailbox may provide the actor with messages in any order. The only requirement is that an actor process one message at a time from its mailbox. Because you cannot determine in advance the order in which an actor processes messages—the order of message delivery is indeterminate—you must ensure that the correctness of an actor-based program does not depend on any specific message order.[7]

The actor model makes such programming practices easy, however, because any sort of data can be contained in an actor message, and also because an actor is able to maintain its own state. Consider, for instance, an actor that sums up two integers and sends the result to a third actor. In the simplest implementation, a single actor message would contain the two integers as well as the continuation where the sum would be sent to.

A different implementation may process integers from separate senders. That implementation would expect a message with a single integer, in addition to a name that uniquely identifies the addition calculation. Since addition is commutative, the order of message transmission does not matter: The addition actor saves away the initial value received via the first actor message. Upon receiving the second integer with a similarly named calculation, the addition actor performs the arithmetic operation and sends the reply.

Consider, however, a version of the arithmetic actor designed to add a set of integers. One problematic approach would be to have each integer message include a lastElement flag indicating whether it is the terminal element of the series. As soon as the actor receives the last element in the series, it could send the result to the continuation. But since we cannot guarantee the message delivery order, the last element may be received in any order, resulting in possibly the premature sending of the result.

You can often alleviate reliance on message ordering by refactoring the actor communication, i.e., reworking the messages' contents. For instance, the message described previously could include the number of elements in the series, instead of the lastElement flag. Throughout this book, we will include tips and techniques to design actor communication that does not rely on message order.

Indeterminacy in the actor model results because an actor's mailbox, or arbiter, can receive and provide messages to the actor in any order. You can't guarantee or even specify the order of message arrival due to the inevitable latencies in message transmission between actors: while a message is guaranteed to eventually arrive, the message's transmission time is unbounded.

As we mentioned in the previous chapter, a programming model based on unbounded indeterminism powerfully captures the nature of concurrent computation. In the actor model, concurrency is the norm, while sequential computation is a special case.