Actors

1.1 Actors Overview - By Carl Hewitt

1. from Parallelism and Concurrency in the Actor Model
2. An Actor is a computational entity that, in response to a message it receives, can concurrently:
   1. send messages to addresses of Actors that it has;
   2. create new Actors;
   3. designate how to handle the next message it receives.
3. There is no assumed order to the above actions and they could be carried out concurrently. In addition, two messages sent concurrently can be received in either order.

2.1 Actor Standard Model-1: Structure

1. Think of actors as [tiny] independent processes/threads. May be: think of an actor as a person. Disassociate "thread" with Java or Linux threads.
   1. Every actor is assigned a unique name/ address. [Similar to pid, but abstract.]
   2. An actor knows the addresses of some of the actors.
   3. An actor does not contain other actors.
2. Each actor has its own (local/private) state.
   1. Its own address space.
   2. Includes a pool (queue? bag?) of messages: mailbox.
   3. There is no shared memory/state among actors.
3. No global clock.

2.2 Actor Standard Model-2: Mailbox

1. Idealized mailbox. Can be empty. Never becomes "full". Do not think: Unix-like mailboxes.
2. actorName ! msg Sender never blocks. No handshake. (Overloading of CSP notation.)
3. Sent messages are never lost.
4. Received messages are "processed", one at a time. The processed msg is no longer in the mailbox.
5. When the mailbox is empty, the actor is idle.
6. Messages may not arrive in the order sent. Even though A sent to B, m1 first, and m2 second, B may receive m2 first, and m1 second.
7. Spurious messages do not happen.

2.3 Actor Standard Model-3: Computation

1. Reactive: Actor computation is performed as a reaction to messages. Other than initialization.
2. Single thread. An individual actor is sequential. A collection of actors is concurrent.
3. Each actor has its own methods. Once-only assignment; recursion; if-exp; no loops;
4. An actor can create others dynamically. It can retain the address of the newly created actor.
5. After a msg is processed, the actor A can become a different actor B.
6. The messages remaining will be processed by B.

2.4 Actor Standard Model-4: Processing a Message

1. Send asynchronous messages. [Send is never blocking.]
2. Restricted to actors whose addresses it has.
3. Can send the address as (part of) a message.
4. Can send messages to self.
5. Sender and receiver can agree on the structure of content. (I.e., marshalling is implicit.)

2.5 Actor Standard Model-5: A Tiny Example

1. We will use a quickly-made-up language to illustrate.
2. Do not imagine an obvious implementation in C++, Java or Scala. Implementation techniques of actors are now so advanced that Akka claims X actors in Y.
3. Let us build an actor that behaves like a variable of type integer.

2.6 Actor Standard Model-5: An Integer Variable

1. intvar: actor(z: integer) {
     val myx: integer = z
     receive msg {
       case msg.op = set(x): myx := x
       case msg.op = get() : msg.sender ! myx
     }
   }
   
   var a: actor = create intvar(5)  // external to the actors
   

2. Repeated assignments are not permissible. Use become

2.7 Actor Standard Model-5: An Integer Variable, contd

1. Repeated assignments are not permissible. Use become

   intvar: actor(z: integer) {
     val myx: integer = z
     receive msg {
       case msg.op = set(x): become create intvar(x)
       case msg.op = get() : msg.sender ! myx
     }
   }
   
   var a: actor = create intvar(5)  // external to the actors
   var i: integer = a ! get()       // i = 5
   a ! set(34)                      // does not return any value
   var j: integer = a ! get()       // j = 34
   

2. Even after a become, the actor a is still available as a target for send.
3. As is, the actor a knows of no other actors. We can mod the above to collect msg.sender as it receives messages.

3.1 Actors' Names

1. Each actor is assigned a unique immutable name ["address", or ref].
2. This name cannot be computed/guessed.
3. An actor can have the name of another at build time.
4. An actor can retain the names of actors that it creates.
5. A name may be sent as part of a msg.

3.2 Encapsulation

1. Encapsulation as used in OOP.
2. An actor has no mechanism to share its state with other actors [other than messaging]
3. An actor cannot access, in its own run-time stack, the internal state of another actor.
4. The state of an actor is changeable only through the actors own actions.
5. Safe Messaging: Messages should have call-by-value semantics. After delivery, the message is only in the address space of the receiver-actor.

3.3 Fair Scheduling

1. Weak fairness. Recall its def in temporal logic.
2. Every actor is eventually scheduled to do its computation.
3. So, even in the presence of actors running an infinite loop or blocked on an I/O or system call other actors are not starved.
4. Every message sent is eventually delivered to its intended mailbox (unless its actor is permanently "disabled").
5. These requirements may make the implementation expensive.

3.4 Location Transparency

1. An actor's address is not based on its location.
2. The actors an actor knows could be on the same core, on the same CPU, or on a different node in a network.
3. A consequence of location transparency is state encapsulation.
4. Location transparent naming facilitates migration of actors to different nodes.

3.5 Mobility

1. Mobility: A computation (can) move(s) across different nodes.
2. Strong mobility: Movement of both code and execution state.
3. Weak mobility: Movement of code only.
4. Transparent Migration.
5. Migration enables load-balancing and fault-tolerance.

3.6 Become

1. Behavior is replaced after one msg is processed.
2. Essentially another actor's behavior substitutes.
3. Adress remains the same.
4. When no "become" is defined, the behavior remains as-is.

4.1 A Stack

1. Build a system of actors that behaves as a stack of integers. From an external entity, the "lead" actor receives request-to-do messages: push(x), pop, top, isEmpty. Reply to the last three requests. Assume valid requests.
2. Architecture. Each actor holds one element of the stack. It also has a reference to the next actor of the stack. If this ref is nil, this is the last actor of the stack.

4.2 A Stack, contd-1

1. We show only push and pop implemented.

   stackNd: actor(elm: actor, lnk: actor) {
       receive msg {
         case msg.op = pop():
           if (elm != NIL) {
             become lnk
             msg.sender ! elm
           }
         case msg.op = push(X):
           P = create stackNd(elm, lnk)
           become create stackNd(create itemvar(X), P)
       }
   }
   

4.3 A Stack, contd-2

1. The top of the stack is the receptionist in this actor system.
2. It was the only actor of the system created externally. It is created with a NIL elm, and NIL lnk.
3. A pop operation changes the stack as follows:

      ---------     ---------      ---------
 --->| 3  | --|--->| 4  |  --|--->| NIL|NIL|
     ---------      ---------      ---------

BECOMES

      ----------     -------      ---------
 --->|forwarder|--->| 4 | --|--->| NIL | NIL|
      ----------     -------      ---------

4.4 A Stack, contd-3

1. Discussion: A stack is not a "good match" for distributed computing – any model. If concurrent processes push and pop from the same stack, there are no guarantees about the order of content received back from pops.

4.5 A Recursive Factorial

aux: actor(n: nat, r: actor) {
  receive msg {
    case msg.op = nat(k): r ! n * k
  }
}

factorial: actor() {
  receive msg {
    case msg.op = fac(n, a):
      if (n = 0) a ! nat(1)
      else {
        F = create aux(n, a)
        self ! fac(n - 1, F)
      }
  }
}

6.1 Actors Long Term Objective

1. "The Actor Model is intended to provide a foundation for inconsistency robust information integration." – Carl Hewitt
   1. We should expect large scale gathering of info to be inconsistent.
   2. Robustness in the presence of inconsistency.
2. "Persistence. Information is collected and indexed."
3. "Concurrency: Work proceeds interactively and concurrently, overlapping in time."
4. "Quasi-commutativity: Information can be used regardless of whether it initiates new work or become relevant to ongoing work."
5. "Sponsorship: Sponsors provide resources for computation, i.e., processing, storage, and communications."
6. "Pluralism: Information is heterogeneous, overlapping and often inconsistent. There is no central arbiter of truth."
7. "Provenance: The provenance of information is carefully tracked and recorded."

6.2 Comparison of Execution Semantics

as of 2009

6.3 Encapsulation Violation

A program written in the Scala Actors shows violation of state encapsulation which may cause two actors to simultaneously execute the critical section.

object semaphorenotok {
  class SemaphoreActor() extends Actor {
    ...
    def enter() {
      if (num < MAX) {
        // critical section
        num = num + 1; }}
  }

  def main(args: Array[String]): Unit = {
    var gate = new SemaphoreActor()
    gate.start
    gate ! "enter"
    gate.enter
  }
}

6.4 Starvation

A program written in the Scala Actors showing an Actor "busy-waiting" for a reply. In the absence of fair scheduling, such an actor can potentially starve other actors. [Figure 3 ref1]

object fairness {
  class FairActor() extends Actor {
  ...
  def act() { loop { react {
    case (v : int) => {
      data = v }
    case ("wait") => {
      // busy-waiting section
      if (data > 0) println(data)
      else self ! "wait" }
    case ("start") => {
      calc ! ("add", 4, 5)
      self ! "wait" }}}
  }}}