Actors: a model of concurrent computation in Distributed

Systems

Amin Saremi

Hamid Mohamadi

General Design Decisions

• The nature of computing system– Sequential processes:

• sequential in nature but can execute in parallel with each other: concurrent Pascal, CSP, shared variable

• Transformation on states, state: map from location to value

– Function transforming data values• Example: dataflow, network of parallel process• Indeterminate applicative system: call-by-value is

used, result is a single value

– Actors: • map each incoming communication to a 3-tuple:

– Finite set of communication to other actors

– A new behavior

– Finite set of new actors created

• Behavior = history sensitive

• There is no presumed sequentiality in the action of actors

• Powerful computational agent than before: possible to specify arbitrary SP by actor system and not vice versa

– Actors may create other actors but CSP don’t create other CSP

• Global synchrony and asynchrony

• Interaction between agents– Shared variables– Communication

• Synchronous: sender & receiver ready, Hoare’s CSP, Minler’s CCS

• Asynchronous: receiver doesn't have to be ready, actor model, dataflow

• Any model of synch is built on asynch

• Synch communication is a special case of buffered asynch communication

– “busy waiting” & recursive computation

Computation In Actor Systems

• Computation in a system of actors is carried out in response to communication sent to the system, communication are contained in task.

• All task that have already been processed may be removed

• The Configuration of an actor system: actors it contains and unprocessed tasks.

• Tasks– Tag for distinguishing

– Target: mail address

– Communication: information to the actor at the target

• Behavior– Actors are said to accept a communication when they

process a task

– Accepting & replacement behavior

• An actor:– Mail address, mail queue

– Behavior, function of the communication accepted

Xn

Xn+1

Y1

task

1 2 n n+1

. . .

Create tasks

Specifies replacement

Create actors

1. . .

Targetcommunication

[k1]

[k2]

Create tasks

Create actors

Life-lines diagram

Programming with actors

• Behavior definition– Each time an actor accepts a communication it

computes a replacement behavior, …

– Behavior definition is expressed as a function of the incoming communication

– Two list of identifiers used in a behavior definition• Value for the first list must be specified when the actor is

created: acquaintance list

• Gets its binding from an incoming communication: communication list

• Creating actors– new expression which return the mail address– <new expression>::= new <beh name> ({expr {, expr}*})

– Address of new actor can bind to identifier using <let command>

– Actors created concurrently by an actor may know each other’s mail address, and all the newly created actor knows is the mail address of the other actor

• Creating tasks– A task is created by specifying a target and a

communication– <send command>::= send <communication> to <target>

• Declaring receptionists– The receptionists are the only actors that are free to

receive communication from outside the system– Set of receptionist my also be changing– Whenever a communication containing the mail

address is sent to an actor outside the system, the actor at that mail address become a receptionist

• Declaring external actors– Declare a sequence of identifiers as external actors

whose behavior is to buffer the communications

• Commands– Purpose: specify actions that are to be carried out– Command to specify a replacement behavior:

• become<expression>

• forwarder: example of behavior– Has one acquaintance, the actor to whom the

communication must be forwarded

• Conditional command– if-then

– case

Examples

• Stacka stack-node with acquaintance content and link

if operation requested is a pop & content< >NIL thenbecome forwarder to linksend content to customer

if operation requested is push thenlet P = new stack-node with current

acquaintances{become stack-node with acquaintances

new- content and P}

• Factorial Rec-factorial with acquaintances self

let communication be an integer n and a customer u

become Rec-factorial

if n = 0

then send [1] to customer

else let c = Rec-customer with acquaintance n and u

{send [n-1 , the mail address of c] to self}

Rec-customer with acquaintances an integer n and a customer u

let communication be an integer k

{send [n*k] to u}

[1][1]

[2][6]

[3,c]

[2,m]

[1,m’]

[0,m’’]

(m,(3,c))

(m’,(2,m))

(m’’,(1,m’))

• External actors– Hold– Respond to a communication telling it to

forwardbuffer with acquaintances content and link

if operation requested is release & content< > NIL then

send content to customer

send release request with customer to link

become forwarder to customer

if operation requested is hold then

let B be a new buffer with acquaintances content and link

{become new buffer with acquaintance new-content and B}

Static Topology

Functionapply

receptionistsm1 m2

configuration

m

def two-inputs-needed (m1,m2,m) [sender, arg]

if sender = m1

then become one-input-needed (m1,m2,second,arg)

else become one-input-needed (m1,m2,first,arg)

fi end def

def one-input-needed (m1,m2,m,new-arg-position, old-arg) [sender , new-arg]

let k = (if new-arg-positio = second then f(old-arg , new-arg) else f(new-arg , old-arg) fi )

{send [k] to m}

send ready to m1

send ready to m2

become two-inputs-needed (m1,m2)

end def

Dynamic topology

• Call expression: Call g[k]

input

fgk

reply

reply

customer request

f g

S’

let x= (call g[k]) {S}

S’’

• Factorial def exp rec-factorai() [n]

become rec-factorial()

if n = 0

then reply[1]

else reply [n * (call self [n-1])]

fi

end def

Insensitive actorsChecking-acc (balance, my-saving) [request]

if (deposit request) then

become <checking-acc with update balance>

send (receipt) to customer

if (show-balance request) then

send [balance] to customer

if (withdrawal request) then

if balance >= withdrawal-amount

then become <checking-acc with update balance>

send [receipt] to customer

else let b= new buffer

and p= overdraft-proc (customer, self, my-savings, balance)

{become insens-acc (b,p)

send [withdrawal request with customer p] to my savings}

Insense-acc (buffer, proxy) [request, sender]

if request = become & sender = proxy

then become <replacement specified>

else send <communication> to buffer

overdraft-proc (customer, my-checking,my-savings,checking-balance) [saving-response]

send [savings-response] to customer

if <savings response is withdrawn>

then send [become, checking-acc (0, my-savings)] to my checking

else send [become, checking-acc (checking-balance, my-savings)] to my checking

Checking-accSavings-acc

request

reply

become

hold

release

bufferOverdraft-proc

References

[1]. G A. Agha, “ACRTORS: A Model of Concurrent Computation in Distributed Systems”, The MIT Press, 1986.