Actor Machines

A machine model for dataow actors and its applications.

Jrn W. Janneck
LTH Report 96, 2011 - LU-CS-TR: 201-247
2011-07-14 (corrections 2013-03-01)
Lund University
Computer Science Department
CONTENTS
Contents
Contents 2
1 Introduction 3
2 Actors and Dataow 5
2.1 Basic notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Actor Transition Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Actors and their Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Actor Machines 9
3.1 Actor machines and their execution . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Actor machine execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Well-formed Actor Machines . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Composition of actor machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 AM
0
: a basic actor machine 14
4.1 Conditions and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Well-constructed machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Graphical notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Using actor machines 18
5.1 Intermediate representation for actor languages . . . . . . . . . . . . . . . . . . 18
5.2 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Code generation and actor machine reduction . . . . . . . . . . . . . . . . . . . 20
5.4 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Bibliography 25
2
CHAPTER 1. INTRODUCTION
Chapter 1
Introduction
Figure 1.1: A network of dataow actors.
The focus of this memo is a machine model for dataow actors in with ring [2], or actors for
short. Actors are the basic computational entities in a dataow program, which is a collection
of actors that communicate with each other by exchanging units of data, called tokens, along
directed point-to-point connections, as depicted in Fig. 1.1. These connections are lossless and
order-preserving, i.e. tokens sent do not disappear before being received, and they are received
in the order in which they were sent. Connections are also buffered, which means that tokens
can be received any time after they have been sent, and the buffer associated with a connection
may be conceptually unbounded (although efcient implementations will typically strive to
keep buffers small).
As a consequence of their buffered communication, actors may execute asynchronously,
i.e. without direct synchronization between them. Each individual actor executes by making
a sequence of steps, also called rings. During each step, an actor may do any of the following
things:
consume input tokens,
produce output tokens,
update its own internal state.
If an actor has state, i.e. variables it uses and modies in the course of its execution, that state
is separate from that of any other actor, which implies that actors are never in a data race over
their state with one another.
3
CHAPTER 1. INTRODUCTION
The execution of an actor usually alternates between two distinct phases. First, it needs to
determine whether it is able to perform some computation, which is usually a result of testing
conditions such as the availability of sufcient input data and possibly also conditions related
to the state of the actor. If the actor could to do several different things depending on which
conditions are satised, the choice among themis also part of the rst phase. The second phase
then consists of the actual execution of the chosen step.
The machine model presented here will describe how an actor goes about this process of
selecting the next thing to do and then doing it. Chapter 2 shortly introduces actors, chapter 3
then describes actor machines in general, while chapter 4 sketches a particular class of actor
machines, both as a more concrete example, and also as the basis for future work. Finally
chapter 5 discusses a number of ways in which we can make use of this kind of machine
model, illustrating them by a few examples.
4
CHAPTER 2. ACTORS AND DATAFLOW
Chapter 2
Actors and Dataow
2.1 Basic notation
In the following, we will discuss dataow, i.e. computation that is performed on sequences of
discrete objects (tokens). Without further talking about the nature of those tokens themselves
we assume that they are all members of some non-empty universe of values, |.
The set of all nite sequences of tokens is denoted as S = |

, and the set of all sequences,

_
prex order
nite and innite, as S

= |

. The empty sequence we write as . Sequences, nite and

innite, are partially ordered by the prex order _, such that a _ b if b begins with the tokens
in a in the order they occur in a. Note that _ is reexive, so a _ a, and also _ a for all
sequences a. If a _ b and a ,= b, we also write a b.
Concatenation is the basic operation on sequences, with a b denoting the sequence that

concatenation
consists of the elements of a followed by those of b. It is nite iff both a and b are. If a is
innite, then a b = a. The empty sequence is the neutral element of concatenation, so that
a = a = a. Concatenation and prex order are related to each other: (1) It is always the
case that a _ a b for any b, and nally, (2) a _ b if and only if c : a c = b.
In the course of their execution, actors can consume and produce tokens from and to any
number of distinct input and output sequences. In order to distinguish those sequences from
one another, we use a set P of labels, each of which we call a port. In discussing the input and
ports
output of an actor or a set of actors, we discuss functions fromP to either the nite or the nite
and innite sequences, S
P
and S
P

, respectively. For brevity, we will use the symbols o = S

P
and o

= S
P

. We extend prex order and concatenation on sequences to these functions as

follows: for any s
1
, s
2
o or o

, s
1
_ s
2
iff p P : s
1
(p) _ s
2
(p), and s
1
s
2
: p
s
1
(p) s
2
(p). Also, we will use the symbol for the function whose value is for each port
p P.
For any nite sequence s, we use [s[ to denote its length, i.e. the number of tokens in it.
[[ = 0, and if a is a token and s a sequence, then [as[ = [s[ + 1. Similarly, for two sequences r
and s, it is always true that [r s[ = [r[ +[s[.
Actors also maintain and update state variables that are not sequences of tokens, but simple
variables
values. As with ports, we use set a of all variables V , and thus an assignment of values to these
variables is a function from V to |, the set of all such functions then being |
V
. To keep things
short, we will use 1 = |
V
.
Finally, if we have a function f : A B, write f[a b] for the pointwise update of f at a,
f[a b]
pointwise update
dened as
f[a b] : x
_
b if x = a
f(x) otherwise
2.2 Actor Transition Systems
Actors are computational entities that transform input sequences into output sequences by
performing a number of steps. During each step, an actor consumes a nite number of input
5
CHAPTER 2. ACTORS AND DATAFLOW 2.3. ACTORS AND THEIR COMPOSITION
tokens and produces a nite number of output tokens. In addition, an actor may have internal
state, and a step may transition from one state to another. In this section we will formalize
these ideas. We start by describing actors as labeled transition systems as follows.
Denition 2.1 (Actor Transition System (ATS)). An actor transition system (ATS) is a pair (, ~),
(, ~)
actor transition
system
with 1oo1, and ~ a strict partial order over . For any v 1, (v, , , v) , .
If is understood, we may write v
s

to mean (v, s, s

, v

) . 3
Intuitively, a transition (v, s, s

, v

) changes the variable assignments from v to v

, and con-
sumes s as input, while producing s

as output. Individual transitions are related by a partial

priority order, which affects the possible choice of transitions that can be taken during the exe-
cution of an actor.
For any transition relation its set of input ports P
in

and its set of output ports P

out

are
input/output ports
dened as the ports which at least one transition consumes input from or produces output to:
P
in

= p P [ (v
1
, s
1
, s
2
, v
2
) : s
1
(p) ,=
P
out

= p P [ (v
1
, s
1
, s
2
, v
2
) : s
2
(p) ,=
Here and in the following we will use the same set P of names for input and output ports.
Whether a given p P refers to an input port or an output port will always be evident from
the context in which it is used, so we will not complicate matters by using two distinct sets of
names for them. An input port with name p and an output port of the same name are in no
way related.
We say that a variable x V is an input variable of if the value assigned to it affects the
input/output
variables
transitions in , i.e. there exists an assignment v 1 and a value a | such that (v, s, s

, v

)
for some s, s

o and v

1, but (v[x a], s, s

, v

) , . The set of all input variables is called

V
in

.
An output variable is one whose value is changed by at least one transition in . In other
words, x is an output variable of iff there is an (v, s, s

, v

) such that v(x) ,= v

(x). The set

of all output variables of is called V
out

.
The set V

= V
in

V
out

is the set of all variables of .

2.3 Actors and their Composition
In order to express complex functionality, several actor transition systems are composed into a
dataow network like that depicted in Fig. 1.1. We will represent the structure of the network by
a partial function from (input) ports to (output) ports, mapping each input port in its domain
1
to the output port that connects to it. Note that this implies the absence of fan-in (as every
input port is connected to at most one output port), and it permits unconnected (open) input
(and output) ports.
Denition 2.2 (Dataow Transition System (DTS), Actor). A dataow transition system (or actor
(, ~, , b)
dataow transition
system (DTS)
for short) is a triple (, ~, , b) such that (, ~) is an actor transition system, chi : P P (the
network function) is a partial function on ports such that dom P
in

and rng P
out

, and
b : dom S is the initial input on its internal input ports. 3
Note that the dataow transition system corresponding to a single actor transition system
atomic vs
composite actor
(, ~) is simply (, ~, , ), i.e. its network is empty, which means that all its ports are uncon-
nected. We call a DTS with an empty network function an atomic actor, and refer to a DTS with
a non-empty network function as a composite actor.
For any actor (, ~, , b), we say that dom is the set of its internal input ports, and P
in

dom is the set of its external input ports.
We will now establish some conditions for composing actors.
Denition 2.3 (Composability). Two dataow transition systems (
1
, ~
1
,
1
, b
1
) and (
2
, ~
2
composability
),
2
, b
2
) are composable iff V

1
V

2
= P
in

1
P
in

2
= P
out

1
P
out

2
= . 3
1
We adopt here the common use of domain of a partial function as being the inverse image of its range, i.e.
dom f = f
1
(rng f).
6
CHAPTER 2. ACTORS AND DATAFLOW 2.4. EXECUTION
Corollary. When (
1
, ~
1
,
1
, b
1
) and (
2
, ~
2
,
2
, b
2
) are composable, it follows that
1

2
=~
1
~
2
= . Also, since their respective sets of input ports and output ports are disjoint, dom
1

dom
2
= and rng
1
rng
2
= .
Once we have a set of pairwise composable actors, we dene the network connecting them
as before in terms of a partial function on ports. However, not all those networks of actors are
valid.
Denition 2.4 (Valid DTS Network). If (
j
, ~
j
,
j
, b
j
)
jJ
is a nite set of pairwise composable
valid network of
actors
dataow transition systems, then : P P is a valid network on them iff

jJ

j
is a partial
function on P. 3
This means that all the
j
and the network have disjoint domains, i.e. that a valid network
on a set of composable actors may only connect previously unconnected input ports of the
actors being composed. In that case, composition becomes a simple joining of all the pieces.
Denition 2.5 (Composition of DTS). If (
j
, ~
j
,
j
, b
j
)
jJ
is a nite set of pairwise composable
dataow
composition
dataow transition systems and : P P is a valid network on them, then their composition
under is the dataow transition system
_
_
_
jJ

j
,
_
jJ
~
j
,
_
jJ

j
,
_
jJ
b
j
_
_
3
2.4 Execution
Running an actor (whether atomic or composite) involves executing a sequence of transitions.
The (execution) state in which we execute a transition is characterized by the input sequences
(q, w)
execution state
q o

available at each (input) port, and the assignment of all the variables w 1. In each
such state (q, w) o

1, we need to (a) identify one of the transitions we can take and then
determine the effect of taking it, i.e. the subsequent (q

, w

). This then becomes the starting

point for the next transition and so forth. The following denition species when a transition
can be taken.
Denition 2.6 (Enabled transition). Given an dataow transition system (, ~, , b), we call a
(, ~, )3(q, w)
enabled transition
transition (v, s, s

, v

) enabled in state (q, w) o

1 iff the following conditions are true:

(1) v = w, (2) s _ q and (3) there is no transition ( v, s, s

, v

) ~ (v, s, s

, v

) such that v = w and

s _ q.
The set of all transitions of (, ~, ) enabled in (q, w) is written as (, ~, )3(q, w).
The DTS (, ~, ) is dead in state (q, w) iff (, ~, )3(q, w) = . 3
Thus, a transition is enabled in a state if its variable assignments are the same as those of
the state, and its input sequences are prexes of the unconsumed input, and the same is not
the case for any other transition that is higher in the priority order.
In the following we will use the composition of the partial network function : P P
s
with a (total) sequence function s o, and we will want to obtain a total function in s o.
We thus dene this composition as follows:
s : p
_
s((p)) p dom ()
otherwise
Now we can dene what it means to execute a dataow transition system. A run is a
sequence of transitions, incrementally consuming input and producing output, and adding
the output produced in each step to the input for the next step, as prescribed by the network
function.
7
CHAPTER 2. ACTORS AND DATAFLOW 2.4. EXECUTION
Denition 2.7 (Run of a Dataow Transition System). A (nite/innite) run of a dataow
DTS run
transition system (, ~, , b) is a (nite/innite) sequence of states (q
i
, w
i
) o

1 (for i 0)
and a (nite/innite) sequence of transitions (v
i
, s
i
, s

i
, v

i
) (for i 0) with the following
properties.
1. q
0

dom
= b
2. for all transitions in the run, (v
i
, s
i
, s

i
, v

i
) (, ~, )3(q
i
, w
i
), i.e. the i-th transition is
enabled in the i-th state
3. q
i
(s

i
) = s
i
q
i+1
4. v

i
= w
i+1
If the run is nite, the sequence of states is one element longer than the sequence of transitions.
The result of the run is the concatenation of all s

i
, i.e.

i
s

i
. The state (q
0
, w
0
) is the initial
state of the run, with q
0
representing the input sequences. The consumed input is

i
s
i
.
A nite run has length N if it includes exactly N transitions (and thus N +1 states). q
N
, the
unconsumed input in its nal state, is called its residual.
A nite run of length N is terminated if the dataow transition system is dead in its nal
terminated run
state (q
N
, w
N
). 3
In the denition above, the rst condition constrains the initial state to make the correct
assignments for the internal input ports. The second condition ensures that a transition is
enabled in the state in which it is taken. Note that among other things this implies that v
i
= w
i
.
The third and fourth conditions also dene the value of the next execution state (q
i+1
, w
i+1
).
The third condition is the dataow condition, which actually establishes how the output of a
dataow condition
step (s

i
in this case) becomes distributed (by composition with the connection function ) and
appended to the input (q
i
), so that after the consumed input in the step is removed (s
i
), the
remainder is the unconsumed input for the next step (q
i+1
). The last condition simply states
that the next variable assignment must be the one specied in this transition.
Note that for nite runs of length N, q
0
(

i
s

i
) =

i
s
i
q
N
.
8
CHAPTER 3. ACTOR MACHINES
Chapter 3
Actor Machines
In practice, executing an actor in accordance with Def. 2.7 alternates between two phases, viz.
the selection of an enabled transition (which involves testing the actors input and its state
variables), and the computation required to determine its effects, i.e. the output sequences
and the new state of the actor. In this chapter we will look at a machine model that captures
the steps required to do these tasks in more detail.
3.1 Actor machines and their execution
First, we need to structure the transition set of an actor. The basic idea is that instead of
simply being a (possibly innite) collection of transitions, the transition set is generated by a
(nite) set of actions a
i
, which are partial functions from input sequences and variable assign-
actions
ment to output sequences and new variable assignment, i.e. a
i
: o 1 o 1. Note that
unlike transitions, which treat input sequences and output sequences as well as the variable
assignments symmetrically, actions have a direction. A transition is computed by applying an
action to an element of its domain: if a
i
is dened for (s, v), and a
i
(s, v) = (s

, v

), then the
action represents the transition (v, s, s

, v

).
Applying (or ring or executing) an action a in a given state (q, w) involves nding an el-
ement (s, v) dom (a) such that s _ q and w = v. Since a is a partial function, there is no
guarantee that such an element will always exist. In order to represent when a transition may
be applied, we will use a nite set of conditions g
j
, which are predicates on the states (q, w), i.e.
conditions
we can equivalently represent them as functions g
j
: o V ars 1, 0 (where a value of 1
means the predicate is true), or subsets g
j
o 1 of those states that satisfy the predicate.
(See also the discussion in section 3.1.2.)
Our model thus uses a state machine to drive the execution of actions and the testing of
conditions. The states are elements of some set , with some initial state
0
.
Denition 3.1 (Actor machine). An actor machine is a structure (, (a
i
)
iI
, (c
j
)
jJ
, ,
0
, , b)
actor machine
for some nite index sets I and J and a nite set of controller states with
the conditions c
j
o 1,
the actions a
i
: o 1 o 1 such that for any (s
1
, v), (s
2
, v) dom (a
i
), it is that case
that for all p P, s
1
(p) _ s
2
(p) s
1
(p) = s
2
(p),
the controller : 2

, with a set of possible commands or instructions

= exec(i, n) [ i I, test(j,
1
,
2
) [ j J,
1
,
2
wait() [
,

0
,
9
CHAPTER 3. ACTOR MACHINES 3.1. ACTOR MACHINES AND THEIR EXECUTION
: P P the network function, a partial function from ports to ports, such that
dom () P
in
and rng () P
out
, with P
in
the input ports of the transition and P
out
its output ports as dened below,
the initial assignment for the internal inputs b : dom S.
3
The notion of input/output ports and of the variables on an actor machine is slightly more
complicated than for a dataow transition system. While in a dataow transition system there
is only a single set of transitions determining the ports and variables, in the case of an actor
machine the actions a
i
and conditions c
j
each have to be taken into account. The ports and
variables of an actor machine are dened as follows:
input/output
variables and ports
of an actor
machine
P
in
=p P [ i I, (s, v) dom a
i
: s(p) ,=
p P [ j J, (s, v) c
j
: s(p) ,=
P
out
=p P [ i I, (s, v) rng a
i
: s(p) ,=
V
in
=v V [ i I, (s, w, s

, w

) a
i
, x | : (s, w[v x], s

, w) , a
i

v V [ j J, (s, w) c
j
, x | : (s, w[v x]) , c
j

V
out
=v V [ i I, (s, w, s

, w

) a
i
: w(v) ,= w

(v)
Given an actor machine A = (, (a
i
)
iI
, (c
j
)
jJ
, ,
0
, , b), its set of transitions is the set =
transitions
(v, s, s

, v

) : a
i
: (s, v) dom (a
i
) a
i
(s, v) = (s

, v

). The sets of variables of A are dened

as they are for actor transition systems: We say that a variable x V is an input variable of A if
the value assigned to it affects the transitions in , i.e. there exists an assignment v 1 and a
value a | such that (v, s, s

, v

) for some s, s

o and v

1, but (v[x a], s, s

, v

) , .
The set of all input variables of A is called V
in
A
.
actor machine
variables
An output variable is one whose value is changed by at least one transition of an actor. In
other words, x is an output variable of A iff there is an (v, s, s

, v

) such that v(x) ,= v

(x).
The set of all output variables of A is called V
out
A
.
The set V
A
= V
in
A
V
out
A
is the set of all variables of actor machine A.
The condition on the actions ensures that if an action is dened (for a given variable as-
signment) for some input sequence, then it will not also be dened for another sequence at the
same port that is an extension of the rst. As a consequence, the following holds:
Corollary. For any action a and any (q, w) o 1, there is at most one (s, v) dom (a) such that
deterministic
actions
s _ q and v = w. 3
Proof: Assume there are two distinct (s
1
, v
1
), (s
2
, v
2
) with those properties. Since v
1
= w and
v
2
= w, we trivially have v
1
= v
2
, so therefore it must be that s
1
,= s
2
, and thus p P : s
1
(p) ,=
s
2
(p). Let us consider such a p where s
1
and s
2
differ. Since s
1
_ q, it must be the case that
s
1
(p) _ q(p), and similarly s
2
(p) _ q(p). In other words, both s
1
(p) and s
2
(p) are prexes of
q(p). If they were of equal length, they would have to be equal, violating the premise that p is a
port where s
1
and s
2
differ. Thus one must be shorter than the other, say s
1
(p). But since they
are both prexes, of q(p), this implies that s
1
(p) is a proper prex of s
2
(p), i.e. s
1
(p) _ s
2
(p)
and not s
1
(p) = s
2
(p). This would violate the denition of an action, thus the corollary must
be true.
This implies that if an action applies in a given situation (q, w), the transition it results in is
uniquely dened. We can therefore say that a (uniquely) computes the transition (w, s, s

, w

) in
a state (q, w) iff (a) (s, w) dom (a) and s _ q and (b) a(s, w) = (s

, w

).
The controller of an actor machine governs the execution of its instructions by mapping
commands
each controller state (identied by a natural number) to a set of possible commands. There are
three kinds of commands, the execution, testing, and wait commands. An exec(i, ) execution
exec(i, )
test(j,
true
,
false
)
wait()
command will execute action a
i
(effectively causing the corresponding transition to be made),
10
CHAPTER 3. ACTOR MACHINES 3.1. ACTOR MACHINES AND THEIR EXECUTION
and then transition to the controller state . The test(j,
1
,
2
) command will test whether
condition c
j
holds in the current state. If it does, it will cause the controller to transition to state

1
, otherwise to state
2
. Finally, the wait() command will cause the controller to transition
to state .
If the controller reaches a state such that () = , the actor machine cannot make
terminal controller
state
progress, and such a state is called terminal.
3.1.1 Actor machine execution
We can now describe the execution of an actor machine. As in the case of actor transition
systems, the state of an actor machine includes unconsumed input sequences q o and a
variable assignment w 1. In addition, it also includes the controller state , with the
initial controller state being
0
. We begin by dening a single step of an actor machine.
Denition 3.2 (Step of an actor machine). Given an actor machine (, (a
i
)
iI
, (c
j
)
jJ
, ,
0
, , b)
AM step
and an execution state (q, w, ) o

1 the actor machine can make a step to the state

(q

, w

) by executing the command K () if one of the following is true:

1. K = exec(i,

) and a
i
computes (w, s, s

, w

) in (q, w) such that q (s

) = s q

(with
s

as dened in section 2.4)

2. K = test(j,
1
,
2
) and (s, w) c
j
, such that s _ q, q

= q, w

= w,

=
1
3. K = test(j,
1
,
2
) and (q, w) , c
j
, q

= q, w

= w,

=
2
4. K = wait(

) and q

= q, w

= w
In the rst case, the output of the step is s

, in all others it is . 3
Executing an actor machine then is simply a sequence of steps:
Denition 3.3 (Run of an actor machine). A (nite/innite) run of an actor machine
AM run
(, (a
i
)
iI
, (c
j
)
jJ
, ,
0
, , b) is a (nite/innite) sequence of states (q
k
, w
k
,
k
) (for k 0)
and a (nite/innite) sequence of commands K
k
(for k 0) such that q
0

dom
= b and for all
k 0 in the run the actor machine can make a step from (q
k
, w
k
,
k
) to (q
k+1
, w
k+1
,
k+1
) by
executing the command K
k
(
k
).
The result of the run is the concatenation of the output computed by all steps, i.e.

k
r
k
with
r
k
the output of step k.
A nite run has length N if it includes exactly N commands (and thus N +1 states). q
N
, the
unconsumed input in its nal state, is called its residual.
A nite run of length N is terminated if the actor machine cannot make a step in its last
termination
state. It is internally terminated if (
N
) = , i.e. its last controller state is terminal. It is
internal vs external
termination
externally terminated if it is terminated but not internally terminated. 3
Since at any point during a run the set (
k
) of instructions that can be executed in state k
may contain more than one entry, actor machines are in general nondeterministic, i.e. for any
given initial state an actor machine may execute more than one run (which may differ not only
in their length, but also in the sequence of instructions they execute), and also compute more
than one result.
3.1.2 Well-formed Actor Machines
While Def. 3.3 describes what a run of an actor machine is, it does not give an algorithm
for constructing such a run, which allows it to sidestep a condition that is rather crucial
when actually implementing actor machines. Suppose we are in state (q
k
, w
k
,
k
), and that
exec(i, ) (
k
). What if there is no suitable (s, v) dom (a
i
) such that v = w
k
and s _ q
k
?
In other words, what happens if the controller allows the action a
i
to be executed in some
error states
state, but a
i
is undened for that state and thus cannot execute? We call such states error states.
11
CHAPTER 3. ACTOR MACHINES 3.2. COMPOSITION OF ACTOR MACHINES
In order to distinguish those actor machines that will never run afoul of this problem from
those that could, it is necessary to construct the set of all possible situations during the execu-
tion of an actor machine, and then require that in all of these the machine will never attempt
to execute an action that is undened in that situation. The basic idea is that an actor machine
should be able to avoid this problem for any initial inputeven when during its run between
any two steps additional input is added to any of its input queues.
1
Denition 3.4 (Execution states of an actor machine). For an actor machine
(, (a
i
)
iI
, (c
j
)
jJ
, ,
0
, , b), the set of possible execution states is the smallest set c o 1
such that
1. q [ q o, q
dom
= b 1
0
c
2. if (q, w, ) c and q _ q

, such that q(p) = q

(p) for all p dom , then (q

, u, ) c
3. if (q, w, ) c and the actor machine can make a step to state (q

, w

) by executing a
command in (), then also (q

, w

) c.
This means that any initial condition in which the internal inputs are set to the values in b is
a possible execution state, any state that can be reached by adding more input to the external
inputs of an execution state, and any state that can be reached by making a step. With this, we
can now dene the conditions for an actor machine to not attempt to execute an action at in
inappropriate time. We will call actor machines that satisfy this condition well-formed, and will
from now on assume that all actor machines we are discussing are well-formed.
Denition 3.5 (Well-formed actor machine). We call an actor machine (, (a
i
)
iI
, (c
j
)
jJ
, ,
0
, )
well-formed AM
well-formed iff for all possible execution states (q, w, ) it is the case that
exec(i,

) () (s, w) dom (a
i
) : s _ q.
3.2 Composition of actor machines
One operation we want to perform on actor machines is composition: given a network of actor
machines, we want to compute a single actor machine that behaves in some sense like the
network. Just as for actors, we rst need to dene when actor machines can be composed into
networks, which again is based on their sets of variables, and input and output ports.
Denition 3.6 (Composability of actor machines). Two actor machines Aand B are composable
iff V
A
V
B
= P
in
A
P
in
B
= P
out
A
P
out
B
= .
As for dataow transition systems, we represent a network of set of pairwise composable
actor machines by a network function connecting input ports to output ports. The validity of
such a network function is dened accordingly.
Denition 3.7 (Valid Network of Actor Machines). If (
k
, (a
k,i
)
iI
k
, (c
k,j
)
jJ
k
,
k
,
k,0
,
k
, b
k
)
kK
valid network of
actor machines
is a nite set of pairwise composable actor machines, then : P P is a valid network on them
iff

kK

k
is a partial function on P. 3
The basic composition of a number of actor machines is their product, i.e. the actor machine
that performs a non-deterministic interleaving of the component actor machines.
Denition 3.8 (Actor Machine Product). Given a nite set of pairwise composable actor ma-
actor machine
product
chines (
k
, (a
k,i
)
iI
, (c
k,j
)
jJ
,
k
,
k,0
,
k
, b
k
)
kK
and a valid network on them : P P,
their actor machine product under is
_

kK

k
, (a
k,i
)
kK,iI
k
, (c
k,j
)
kK,jJ
k
,

kK

k
, (
k,0
)
kK
,
_
kK

k
,
_
kK
b
k
_
where

kK

k
is the product controller dened as
product controller
1
The ability to add more input at any point between steps without running actions in situations in which they are
not dened will allow us to interleave the execution of networks of communicating actors.
12
CHAPTER 3. ACTOR MACHINES 3.2. COMPOSITION OF ACTOR MACHINES

kK

k
: (
k
)
kK

_
kK

k
(
k
)
3
In general, this product machine is not very interesting for practical applications, since it
essentially describes a simulation of a network of actor machines. The kinds of compositions
we are interested in would take advantage of the special properties of actions and conditions,
and eliminate testing instructions as much as is feasible. This will require constraining the
admissible actions and conditions, and to dene composition in a way that takes advantage
of those constraints, often resulting in a composite machine that is more limited than the full
actor machine product.
Before turning to this, however, we will close this section with the following proposition:
Proposition 3.1 (Well-formed actor machines closed over product). For any set of pairwise com-
posable actor machines and any valid network over it, the resulting actor machine product is well-
formed. 3
This follows from the fact that in any well-formed actor machine, we may add additional
inputs to external ports in any state of the controller. In the AM product, the various compo-
nent machines operate in some interleaving, which means that between the steps pertaining
to one component machine any number of other steps may occur that relate to other compo-
nent machines. However, those steps may only change external variables and add tokens to
external input ports (due to pairwise composability and the validity of the network)more
precisely, those ports and variables are external to the original component machine, although
they are of course internal to the machine product, and thus none of the components will
ever run into an error state, and consequently neither will their product.
13
CHAPTER 4. AM
0
: A BASIC ACTOR MACHINE
Chapter 4
AM
0
: a basic actor machine
In this chapter we will dene a family of actor machines that we will use to represent and ma-
nipulate dataow programs in the CAL actor language. We will call this family AM
0
, because
of its basic and simple structure.
Some notation rst. If f is a (total or partial) function from ports to nite sequences, then
[f[ denotes the function from ports P to the natural numbers (including 0) N
0
such that
[f[ : p
_
[f(p)[ if p dom f
0 otherwise
whenever f(p) is dened. Given two functions n, m : P N
0
, we extend the total order on
N
0
to a (partial) order on these functions by saying that n m iff for all p P we have n(p)
m(p). Similarly, we dene addition on these functions such that (n + m) : p n(p) + m(p).
We dene a lower bound and an upper bound operation on these functions as follows:
n . m : p minn(p), m(p)
n m : p maxn(p), m(p)
For any sequence s, its restriction to n shall be the sequence s
n
_ s such that [s
n
[ =
min[s[ , n. Similarly, for a function from port to sequences s o, its restriction to an r :
P N
0
shall be s
r
: p s(p)
r(p)
.
4.1 Conditions and Actions
AM
0
provides two kinds of conditions. Input conditions are written p, n, where p is an input
input conditions
p, n
port, and n a natural number > 0. A state (q, w) p, n iff [q(p)[ n, i.e. there are at least n
tokens waiting on input port p. Note that input conditions remain true when tokens are added
to ports.
The other kind of condition in AM
0
is called a guard. A guard g o is a general predicate
guards
[g, in
g
]
on input sequences but with the additional requirement that there be an in
g
: P N
0
with
the following two properties:
1. (q, w) g (q
in
g
, w) g
2. (q, w) g = q

_ q : (q

, w) g
This means that in order to determine whether a given (q, w) satises g, it sufces to look
only at the tokens up to the bounds specied in in
g
. It also means that once a (q, w) has been
found to satisfy g, adding more input tokens will not unsatisfy the guard.
We use G to refer to the set of guards in an actor machine, and it comes with a reexive
partial order such that g
1
g
2
= g
1
g
2
, i.e. if an execution state satises g
1
, it also
14
CHAPTER 4. AM
0
: A BASIC ACTOR MACHINE 4.2. INTERPRETATION
satises g
2
(we say that g
1
implies g
2
).
1
The set of all guards implied by g is written as

g = g

[
g g

. Note that since is reexive, g

g .
The actions in AM
0
are constrained to always consume and produce the same number of
AM
0
action
[a, in
a
, out
a
, a]
tokens at each input and output port. In other words, suppose for some action a it is the case
that a(s
1
, v
1
) = (s

1
, v

1
) and also a(s
2
, v
2
) = (s

2
, v

2
), then it must be the case that for all ports
p P, we have [s
1
(p)[ = [s
2
(p)[ and also [s

1
(p)[ = [s

2
(p)[. This means that for each action a we
have functions in
a
, out
a
: P N
0
such that if a(s, v) = (s

, v

) then [s[ = in
a
and [s

[ = out
a
.
Each action a is also associated with the set of guards a G that need to be satised in order
action conditions
for the action to be executable (its action conditions), i.e. it must be the case that

g a
g dom a
4.2 Interpretation
In general, we consider an interpretation of an actor machine a mapping from its controller
interpretation
states to some kind of information about the environment that the machine is operating in,
i.e. about (q, w). The idea is that by testing conditions the machine gradually accumulates
information about the environment that allows it to safely execute an action.
In the case of AM
0
, the basic interpretation J() of each controller state provides pieces of
basic AM
0
interpretation
information: a lower bound T

: P N
0
for the number of tokens available at each input
port, and a set G

of guards satised in that controller state.

We can compute the interpretation incrementally by constructing a sequence of partial in-
terpretations J
k
: N
P
0
2
G
for some states dom J
k
, as well as instructions to be
elaborated E
k
as follows, with J
k
() = (T
k,
, G
k,
).
1. J
0
=
0
([b[ , )), and E
0
= (
0
, e) [ e (
0
)
2. Suppose we are at step k, with J
k
and E
k
. If E
k
= , we are done and the result is
J :
_
J
k
() if dom J
k
([[ , ) otherwise
3. Otherwise, pick a (, e) E
k
.
4. Depending on the formof the instruction e and whether the subsequent state has already
been visited, we can compute J
k+1
, which is identical to J
k
, except at one controller state
which we shall call

. This means that we need to dene the values for

J
k+1
(

) = (T
k+1,
, G
k+1,
). We do this as follows.
if e = test(p, n ,

) and

, dom J
k
, then
T
k+1,
= T
k,
[p n]
G
k+1,
=
if e = test(p, n ,

) and

dom J
k
, then
T
k+1,
= T
k,
. T
k,
[p n]
G
k+1,
= G
k,

if e = test(g, s

, s

) and

, dom J
k
, then
T
k+1,
= T
k,

G
k+1,
=

g G
k,
1
Note that we do not require the reverse, i.e. it might be the case that g
1
g
2
, but that does not mean that
automatically g
1
g
2
.
15
CHAPTER 4. AM
0
: A BASIC ACTOR MACHINE 4.3. WELL-CONSTRUCTED MACHINES
if e = test(g, s

, s

) and

dom J
k
, then
T
k+1,
= T
k,

G
k+1,
= G
k,
(

g G
k,
)
if e = exec(a
i
,

) and

, dom J
k
, then
2
T
k+1,
= T
k,
in
i
+out
i

G
k+1,
=
if e = exec(a
i
,

) and

dom J
k
, then
T
k+1,
= T
k,
. (T
k,
in
i
+out
i
)
G
k+1,
=
5. Now we set
E
k+1
=
_
E
k
(, e) if

dom J
k
J
k
(

) = J
k+1
(

)
E
k
(, e) (

, f) [ f (

) otherwise
6. Go to step 2
It is easy to see that this construction is terminatingthere are only nitely many controller
states, and once a state is constructed, i.e. once it is in (the non-decreasing) dom J
k
, its interpre-
tation only becomes smaller, i.e. the input sizes become smaller and guards that are satised
get removed. Although intuitive, it is a little more technical to show that the algorithm always
terminates with the same result, irrespective of the order in which the choice in step 3 is made.
We will omit the proof.
4.3 Well-constructed machines
One thing the interpretation above allows us to do is to establish when an AM
0
machine is
built in such a way that its actions (and guards) can always be appliedit is in essence a
conservative approximation to the notion of well-formedness from Def. 3.5.
Denition 4.1 (Well-constructed AM
0
machine). Given an AM
0
machine with basic interpre-
tation J, we call the machine well-constructed if and only if the following is true (we will again
say that J() = (T

, G

)):
for every guard instruction test(g,
1
,
2
) (), it is the case that in
g
T

and
for every action execution instruction exec(a,
1
) (), it is the case that in
a
T

and
also that a G

.
The notion that well-constructedness is a conservative approximation to well-formedness
is expressed in the following proposition, the proof of which we shall omit here.
Proposition 4.1. A well-constructed AM
0
machine is always well-formed.
4.4 Graphical notation
We now turn to some uses of actor machines, specically those of the AM
0
variety. We will
mostly be interested in their controllers, which we will represent graphically as shown in
Fig. 4.1. The ellipses represent controller states, and are usually labeled with their interpre-
tation, in this case a vector describing our knowledge about the conditions of the actor ma-
chine. The diamond denote test instructions, the solid arrow with the full head being the
true branch, and the dotted arrow with the hollow head being the false branch. The label
identies the condition being tested. The rings are wait instructions, and the boxes are exec
instructions, labeled with the action being executed.
2
We use here a convention for the composition out
i
for ports p dom , we dene out
i
(p) to be 0.
16
CHAPTER 4. AM
0
: A BASIC ACTOR MACHINE 4.4. GRAPHICAL NOTATION
Figure 4.1: A very simple actor machine controller.
17
CHAPTER 5. USING ACTOR MACHINES
Chapter 5
Using actor machines

actor S pl i t ( ) A P, N:
A1: action A: [ v] P: [ v]
guard v >= 0
end
A2: action A: [ v] N: [ v]
guard v < 0
end
end

Listing 5.1: A simple CAL actor.
5.1 Intermediate representation for actor languages
The foremost use of actor machines is as intermediate representation for actor languages, such
as the CAL actor language [1]. Actors written in CAL can easily be translated into AM
0
, since
they are already structured in actions, guard, and input conditions.
Fig. 5.1 depicts a direct translation of the Split actor in Listing 5.1. As we shall see in the
next section, this representation of the actor is not a very good one, and it can be improved
upon in many ways. Nonetheless, it is correct, and can be obtained from the CAL program by
purely syntactical transformation.
Priorities in the CAL language are simply translated into the actor machine controller by
priorities
making sure that all higher-priority actions are not enabled before a lower priority action is
being executed. For example, in Fig. 5.2, state 11X has all conditions for A2 tested (viz. the
second condition, the availability of two tokens on the input port), but before it can execute
the second action it needs to test the third condition (A1s guard), which has to be false (in
state 110), otherwise it is A1 that needs to be executed.

actor Foo ( ) X Y, Z:
A1: action X: [ v] Y: [ v]
guard v >= 0
end
A2: action X: [ v , w] Z: [ v + w]
end
priority A1 > A2; end
end

Listing 5.2: An actor with priorities.
18
CHAPTER 5. USING ACTOR MACHINES 5.2. OPTIMIZATION
Figure 5.1: Basic actor machine for the Split actor in listing 5.1. The conditions are c1 : (X, 1),
c2 : v >= 0 [v = X[0]], and c3 : v < 0 [v = X[0]].
5.2 Optimization
Actor machines can implement actors in various ways, and even though they are equivalent
in the sense that they lead to the same sequences of actions being executed under the same
circumstances, they may still differ in relevant ways. Finding better ways of representing an
actor can often be accomplished by improving on or optimizing an actor machine.
The simplest optimizations are based entirely on the structure of the controller itself, with-
out reference to the content of either the conditions or the actions. Fig. 5.3 shows a modication
of the controller in Fig. 5.1. Note that the states 101 and 1X1 in the original controller lead to
state fusion
identical instructionsexec(Split.A2, XXX). They are therefore equivalent, and can be fused.
The same applies to state 11X and 110.
Another kind of optimization is based on the analysis of guards and actions. Suppose, for
program analysis
example, that we would be able to determine that the conditions c2 and c3 in the Split actor
are logical inverses of each other. In that case, testing either condition would yield truth values
for both, and we could simplify the controller in Fig. 5.3 even further to yield the controller in
Fig. 5.4.
19
CHAPTER 5. USING ACTOR MACHINES 5.3. CODE GENERATION AND ACTOR MACHINE REDUCTION
Figure 5.2: Basic actor machine for the Foo actor in listing 5.2. The conditions are c1 : (X, 1),
c2 : (X, 2), and c3 : v >= 0 [v = X[0]]
5.3 Code generation and actor machine reduction
Code generation, i.e. deriving an implementation of an actor machine for a given platform,
is in general very dependent on the specic properties of the target. However, if the target
is a sequential processor and we want to generate software from an actor machine, one near
universal component of generating code is to sequentialize the operations performed by the
machine. In particular, we can remove nondeterministic branches from the controller.
Suppose we have a multi-instruction actor machine (MIAM), such as the on in Fig. 5.2
reduction
states XXX and 1XX permit more than one instruction to be executed. Areduction to a single-
instruction actor machine (SIAM) is performed by picking one of the instructions in each state
that permits more than one, and remove states and instructions that become unreachable in
this manner.
For example, if we choose to test c1 in state XXX and c3 in state 1XX, the resulting reduc-
tion of the controller in Fig. 5.2 can be seen in Fig. 5.5.
On the other hand, if we instead pick the test of c2 in state XXX (and c3 in state 1XX as
before), we get the reduction in Fig. 5.6. While this reduction may be slightly bigger than the
previous one, it is not necessarily a bad choice. This is because an actor machines performance
(in terms of the number of tests it needs to execute in order to re a sequence of actions for a
given input stream) will in general depend on its input data.
20
CHAPTER 5. USING ACTOR MACHINES 5.4. COMPOSITION
Figure 5.3: Simplication of the actor machine in Fig. 5.1 by fusing the state 101 with 1X1,
and the state 110 with state 11X, based on the fact that the controller maps them to identical
instructions.

actor Bar ( ) X Y:
Do: action X: [ v] Y: [ f ( v ) ]
end
end

Listing 5.3: A very simple actor.
5.4 Composition
In section 3.2 we dened the composition of a network of actor machines as the product ma-
chine (Def. 3.8), noting that it is not a very useful way of constructing the composition in
practice. One reason for this is that the product machine tends to be very large, and another
that it isnt very efcient with respect to the number of steps it needs to make in order to
execute a dataow program.
Consider the program in Fig. 5.7 that composes actors Foo (Listing 5.2) and Bar (List-
ing 5.3). Bars controller is shown in Fig. 5.8, its condition c1 : (Bar.X, 1).
Typically the goal is to create a more efcient (and smaller) controller than the product
machine. The basic idea toward this is based on the observation that internal queues are ex-
clusively written to and read from by actions executed by the controller. This enables the
extended
interpretation
controller to keep track of how many tokens are in each of those queues at any point in time,
and to represent that knowledge as part of its state by way of an extended interpretation.
In our example, that interpretation of the states of composite controller would include (a)
the status of the one condition of Bar, the three conditions of Foo, and on top of that a natural
number denoting the number of tokens in the single internal connection between those actors.
Thus the initial state could be written as X

XXX 0: the condition of Bar, the

symbol for
readability, the conditions of Foo, and nally the token count in the single internal queue after
the dash.
However, as the rst two conditions of Foo are input conditions, dependent only on the
number of input tokens available to Foo on X, we can actually compute their values directly
21
CHAPTER 5. USING ACTOR MACHINES 5.4. COMPOSITION
Figure 5.4: Simplication of the controller in Fig. 5.3 based on the fact that the conditions c2
and c3 are inverses of each other.
Figure 5.5: Reduction of the controller in Fig. 5.2 by choosing to test condition c1 in state XXX
and c3 in state 1XX.
from the knowledge of the number of tokens in the internal queue. Since that is 0 initially,
those conditions are false, and we can start with initial state X

00X 0.
Starting from this initial state, we can create a composite controller in a process we call
abstract simulation
1
.
The algorithm in Listing 5.4 outlines the basic idea of abstract simulation. Starting with
the initial state of the network in the todo list of states to be processed, we proceed until that
todo list is empty, picking one of the states to be processed, and adding it to the state space
of the composite. For each state that has a non-empty set of instructions, we use a heuristic
H to pick a non-empty subset of instructions to "execute". We do so by adding all successor
states of all instructions we picked to the todo list, after computing the proper internal queue
lengths and resolving all internal conditions accordingly, as we did above for the initial state
of the example.
As we can see, the choice heuristic H is in essence controlling the direction of abstract
choice heuristic H
simulation, AS(H). For any non-empty set of instructions S, the heuristic has to satisfy two
conditions, viz. that H(S) ,= and H(S) S.
1
The term is chosen in analogy to the common program analysis technique of abstract interpretation, because it
essentially amounts to executing (or simulating) the dataownetwork without knowing the values of the tokens being
computed on, exploring multiple execution paths in the process.
22
CHAPTER 5. USING ACTOR MACHINES 5.4. COMPOSITION
Figure 5.6: Reduction of the controller in Fig. 5.2 by choosing to test condition c2 in state XXX
and c3 in state 1XX.
Figure 5.7: A composition of Bar and Foo.
There are two extreme cases for H. The rst is a heuristic that will always pick a single
instruction, leading to an abstract simulation AS
1
that will always result in a single-instruction
composite machine.
The other extreme is the identity function H(S) = S which always picks all instructions in
a state. This results in full abstract simulation AS

, which explores the entire state space of the

product machine.
Fig. 5.9 depicts a controller for the composite in Fig. 5.7, generated by an AS
1
algorithm.
23
CHAPTER 5. USING ACTOR MACHINES 5.4. COMPOSITION
Figure 5.8: The controller of the actor in Listing 5.3.

todo : = networkInitialState ;
: = ;
while todo = do
s : = choose(todo) ;
todo : = todo \ {s} ;
: = {s} ;
if instructions(s) = then
I : = H(instructions(s)) ;
I(s) : = I ;
todo : = todo

iI
successors(i) \ ;
end
end

Listing 5.4: AS(H): the basic algorithm for abstract simulation, with H being the choice heuris-
tic.
Figure 5.9: A controller for the composite in Fig.5.7
24
BIBLIOGRAPHY BIBLIOGRAPHY
Bibliography
[1] Johan Eker and Jrn W. Janneck. CAL Language Report. Technical Memo UCB/ERL
M03/48, Electronics Research Lab, University of California at Berkeley, December 2003.
18
[2] Edward A. Lee and Thomas M. Parks. Dataow process networks. Proceedings of the IEEE,
83(5):773801, May 1995. 3
25