On the Actor Model and “mailboxes”

Carl Hewitt clarified the relationship between his formulation of the Actor Model and one particular version of it (Karmani & Agha, 2011). The following is a message from Hewitt sent to Lambda The Ultimate in 2013 (http://lambda-the-ultimate.org/node/4853 ). This is a good reference to better understand the Actor Model and how it can be “implemented.” I note this seeing that some Erlang-related materials suggest or take for granted that “mailboxes” are an essential part of the Actor Model.

This is Hewitt’s explanation:

“Fog Cutter” model illustrates Actor Model issues

[Karmani and Agha 2011] promoted the Fog Cutter [so named by Kristen Nygaard] model in which each computational agent is defined to have a mailbox, thread, state, and program. However, the Fog Cutter is not a general model of Actors because of the following differences:
Each computational agent has a ‘mailbox’. But if everything that interacts is an Actor, then a mailbox must be an Actor and so in turn needs a mailbox which in turn…[ Hewitt, Bishop, and Steiger 1973] Of course, mailboxes having mailboxes is an infinite regress that has been humorously characterized by Erik Meijer as “down the rabbit hole.” [
Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)]
A computational agent ‘terminates’ when every computational agent that it has created is ‘idle’ and there is no way to send it a message. In practice, it is preferable to use garbage collection for Actors that are inaccessible. [Baker and Hewitt 1977]
Each computational agent executes a ‘loop’ using its own sequential ‘thread’ that begins with receiving a message followed by possibly creating more computational agents, sending messages, updating its local state, and then looping back for the next message. In practice, it is preferable to provide “Swiss cheese” by which an Actor can concurrently process multiple messages without the limitation of a sequential thread loop.
A computational agent has a well-defined local ‘autonomous’ ‘state’ that can be updated while processing a message. However, because of indeterminacy an Actor may not be in a well-defined local independent state. For example, Actors might be entangled with each other so that their actions are correlated. Also, large distributed Actors (e.g.
www.dod.gov) do not have a well-defined state. In practice, it is preferable for an Actor not to change its local information while it is processing a message and instead specify to the information to be used in how it will process the next message received.

The Fog Cutter model has been extremely useful for exploring issues about Actors including the following alternatives:
Reception order of messaging instead of mailbox
Activation order of messaging instead of thread
Behavior instead of state+program

In practice, the most common and effective way to explain Actors has been operationally using a suitable Actor program language (e.g., ActorScript) that specifies how Actors can be implemented along with an English explanation of the axioms for Actors.

For more information see Actor Model of Computation

By Hewitt at 2013-12-03 18:40 | LtU Forum | previous forum topic | next forum topic | other blogs | 1050 reads

(Source: http://lambda-the-ultimate.org/node/4853  — The same explanation is contained in C. Hewitt’s paper “Actor Model of Computation”, 2013 – http://arxiv.org/ftp/arxiv/papers/1008/1008.1459.pdf )