Actors: a model of concurrent computation in Distributed Systems Amin Saremi Hamid Mohamadi.
-
Upload
emerald-barnett -
Category
Documents
-
view
215 -
download
1
Transcript of Actors: a model of concurrent computation in Distributed Systems Amin Saremi Hamid Mohamadi.
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.