An Actor-Based Programming System

Roy J. Byrd
Stephen E. Smith
S. Peter de Jong*

IBM Thomas J. Watson Research Center

Yorktown Heights, New York 10598

ABSTRACT: A programming system is described with Instead of directly implementing SBA in P L / I , we

which applications are built by defining collections of decided to first develop a programming system which pro-
communicating objects, called actors. The actor program- vides the primitives needed by SBA. Such a programming
ming system provides a uniform environment in which system should support intelligent objects which communi-
distributed applications can be automated in a highly mod- cate via messages, the ability to create instances of objects
which have common structure and behavior, and the abili-
ular and efficient manner. The system's design is based on
ty to easily modify the behavior of an object.
the formal theory of actors, with certain modifications
made for the sake of efficiency. We describe our view of
Our approach was to begin with the actor formalism
the actor system, and an implementation of that view. We
developed at the M.I.T. Artificial Intelligence Lab (Baker
also discuss applications built on, and contemplated for,
(1978), Lieberman (1981)), and adapt if for use as a pro-
the actor system.
gramming system. The actor formalism has the following
properties, which are ideally suited to our objective.
1. Instances of actor types are the executing and communi-
1. Introduction. cating objects in the system. Their behavior is speci-
fied by a "script" and they have memory which per-
This paper describes a programming system developed
sists between invocations.
within the context of the System for Business Automation
2. An actor communicates with other actors, known as it's
(SBA) project (de Jong (1980), Zloof and de Jong (1977), "acquaintances", via messages. It is transparent to an
de Jong and Byrd (1980)). In SBA, "boxes" represent actor sending or receiving a message whether the oth-
business objects like documents, files and memos. Initially er actor is at the same node or a different node in a
humans operate on the objects. Gradually the business network of computers.
processes are automated by imparting intelligence to the 3. Actors execute asynchronously, upon receipt of a mes-
objects through the 2-dimensional SBA programming lan- sage.
guage. Eventually one obtains an automated business 4. Actors are highly modular with well defined intorfaces.
system in which intelligent business objects communicate One cannot look inside an actor. One only knows its
among themselves without human intervention. These behavior in terms of the types of messages it accepts
systems are naturally distributed, and we envision a net- and the way it responds to those messages.
work of processing nodes representing the functional com- 5. Every object is an actor; in particular, the messages are
ponents of a business organization, with objects such as actors.
memos and invoices flowing between these nodes.
The actor-based programming system intentionally
deviates from a pure actor formalism in the granularity of
the actor objects, and in the way in which they are de-
Permission to copy without fee all or part of this material is granted fined. In a pure actor system absolutely everything is an
provided that the copies are not made or distributed for direct actor, actors are defined in terms of other actors, i.e. there
commercial advantage, the ACM copyright notice and the title of the are no numbers or arrays. In the actor-based program-
publication and its date appear, and notice is given that copying is by
permission of the Association for Computing Machinery. To copy ming system the objects implementing an application be-
otherwise, or to republish, requires a fee and/or specific permission. have as actors. However, the internal specification of an

* Current address: Massachusetts Institute of Technology

Cambridge, Massachusetts 02139
©1982 ACMO-89791-075-3/82/O06/O067 $00.75

67
actor is PL/I-like and contains PL/I-like data types. it possible to achieve a match between the amount of
While an actor specification can be as small as two lines it parallelism and communication in the system and the capa-
can legitimately grow to be hundreds of lines. bilities of the available processors.

Our break from a pure actor formalism is basically There are other object oriented programming disci-
pragmatic, but is vital to the success of the actor formal- plines which have properties similar to actors. In particu-
ism as a programming discipline. At its origins, actors lar, SIMULA (Birtwistle, et al. (1973)), Smalltalk (IngaUs
were presented as a new model of computation, not as a (1978)), and "abstract data type" languages like CLU
new programming language (cf. Baker(1978)). Users were (Liskov, et al. (1977)). A thorough comparison of these
expected to program in LISP, and use a compiler to gener- programming languages would be of interest, but would
ate computations in terms of actors. Our objective is a take a considerable amount of effort, and is outside the
system in which users can directly program the actors intent of this paper. We adopted the actor formalism
participating in an application. because it most closely matched SBA's requirements, it
provided a sound theoretical basis to build upon, and it
In addition, a pure actor system implies an over- promised to yield the most compact and efficient imple-
whelming amount of parallelism and communiaation. mentation of the programming system that we sought.
While this is appropriate for an array of microprocessors
(cf. Hewitt(1980)), we do not foresee this kind of process- Section 2 introduces an example which will be referred
ing configuration becoming readily available in the near to throughout the paper. It will be used to demonstrate
future. Instead, we expect a local network of conventional both how actors are defined, and how applications can be
single processor computers. The cost of a message trans- implemented as a collection of communicating actor ob-
mission in this environment will be large enough to pre- jects. Section 3 describes the basic constructs in the actor
clude the level of message communication in a pure actor language, and completes the definition of the major actors
system. By defining fewer larger actor objects one can in the example application. Section 4 describes additional
perform more computation within each actor and reduce features not needed in the example. Section 5 deals with
the degree of communication between actors. This makes the implementation, in particular, those aspects of the

PERSON
- I
NAME:SUE I /INAME: SAM i
L
',CALENDARIjl~
iTiT i
I I

ICALENDAR1
L J

r l
IPERSON ~-~
I I
INAHE: ERIC[ INAME: JOE I
I I
CALENDAR~I
iTii i
I
t
i CALENDAR I iCALENDARI
I I
I I

Figure 1. Scheduling a Meeting.

68
implementation concerning performance. Section 6 sum- This solution to the scheduling problem exploits many
marizes applications built with the current implementation. of the properties of actors we feel to be useful. The PER-
Section 7 summarizes the paper and describes the current SON and C A L E N D A R actors can be resident on separate
status of the project. personal computers, and distribution is obtained by merely
sending messages to those actors. When MEETING
broadcasts itself to the CALENDARs it initiates concur-
2. An Example. rent execution of the CALENDARs, thus taking advantage
of natural parallelism in the application.
As an example of a business application implemented
as a collection of actors, we consider the process of sched-
3. Actors.
uling a meeting. A MEETING can be partially character-
ized by a list of its PARTICIPANTS, its DURATION and
Defining Actor Types.
the TIME of the meeting. (We ignore other aspects of
Actor types are defined using the actor language,
meetings such as topic, location, etc.) A meeting can be
which is built on a subset of P L / I . An actor type defini-
scheduled by inspecting the CALENDAR of each PER-
tion has the following structure:
SON on the participant list, and scheduling the meeting for
the earliest time period of the required duration which all 1. An ACTOR statement, giving the name and attributes
calendars indicate to be currently unscheduled. of the actor type.
2. Zero or more INSTORE statements declaring instance
We will implement the scheduling process with the variables.
following actor types: MEETING, PERSON, CALEN- 3. Zero or more D E C L A R E statements declaring automat-
DAR, TIME INTERVAL, T I M E I N T E R V A L L I S T , ic variables.
LIST, FIRST, and NEXT. Figure 1 depicts the major 4. Zero or more ACCEPT statements defining the actor's
actors involved, with the arrows emanating from each responses to messages.
actor representing its "acquaintances"--other actors known 5. Subroutines which can be invoked from within the AC-
to it, and with which it can communicate. The scheduling CEPT clauses.
process could proceed as follows: 6. An END statement.
Figure 2 shows the overall structure of the definition of
1. A MEETING actor is created with a LIST of PERSON the MEETING actor described in the preceding example.
actors as its PARTICIPANTS acquaintance. The du-
ration field is initialized. MEETING: ACTORSERIAL;
2. The MEETING actor cycles over the PERSON actors INSTORE
PARTICIPANTS ACQ,
on its LIST of PARTICIPANTS. It (asynchronously)
DURATION FIXED,
broadcasts itself to all of the C A L E N D A R actors TIME FIXED,
belonging to those PERSONs. COUNT FIXED,
3. The CALENDAR actors, upon receipt of an unsche- POSSIBILITIES ACQ;
duled MEETING, create and return a DECLARE
P ACQ;
TIME INTERVAL LIST containing the
ACCEPT('CREATE')
TIME INTERVALs which a) are currently free, and
b) exceed the DURATION required for the MEET- ACCEPT('TIME INTERVAL LIST')
ING. ° , •

4. When a returned TIME INTERVAL LIST is re-

END;
ceived, the MEETING actor sends it to the POSSI- Figure 2. Outline of MEETING actor script.
BILITIES acquaintance, which is also a
TIMEwlNTERVAL LIST. POSSIBILITIES updates One of the attributes which can be specified in the
it's state to the intersection of its current state with ACTOR statement is SERIAL. When specified, it forces
the state of the TIME INTERVAL LIST message. the messages sent to an instance of the actor to be proc-
5. When all C A L E N D A R actors have responded, the essed sequentially. Specifying NONSERIAL allows con-
MEETING sets its TIME field to be the TIME of the current invocations of an actor.
first TIME INTERVAL in its POSSIBILITIES ac-
quaintance. The newly scheduled MEETING actor The data types supported for automatic and instance
again broadcasts itself to the original set of CALEN- variables are the P L / I data types plus the A C Q U A I N -
DARs for inscription. TANCE (ACQ) data type. An acquaintance variable can

69
contain the name of an actor. Having the name of an CREATE(type,parameter)
actor allows reference to that actor in a message transmis-
sion. The internal form of the name is not revealed to the C R E A T E causes instance storage for an actor of type
programmer. "type" to be allocated. If the script for that type contains
an A C C E P T ( ' C R E A T E ' ) clause, the script is invoked and
The I N S T O R E variables define the c o n t e n t s of in- the create clause executed. The create clause specifies
stance storage for actors of the type being defined. The processing to be performed at the time of creation. The
instance storage of an actor is a piece of storage which "parameter" in the C R E A T E operation is an actor which
identifies the actor type, and contains variables whose can be referenced in the create clause. In the absence of
values represent the current state of the instance. This an A C C E P T ( ' C R E A T E ' ) clause, the instance storage for
state persists from one invocation of the actor to the next. an actor is created with uninitialized instance variables.
Instance storage, therefore, is the p e r m a n e n t representa- C R E A T E is a function which returns the new actor as its
tive of the actor instance within the c o m p u t i n g system. value.
W h e n an actor serves as the message in a transmission, it
is the instance storage which is actually transmitted. Actor Communication.
A n actor c o m m u n i c a t e s with it's acquaintances by
Each A C C E P T s t a t e m e n t identifies a message type to sending them messages. Send operations are provided for
be accepted, and the code to be executed upon receipt of a initiating message transmissions. A message transmission
message of the specified type. If the code for an accept has four components which are set by the send operations.
clause comprises more than one statement, it is enclosed in The first two are the target, which is the actor to receive
a D O - E N D block. the message, and the message actor itself. A third compo-
nent, the customer, is the actor which should receive the
The source language specification for an actor type is reply message if one is generated as a result of the mes-
compiled. This compilation process produces an executa- sage transmission. The c u s t o m e r is frequently, but not
ble script file and a template for the instance storage. In- necessarily always, the actor initiating the send operation.
stance storage for actor's of type M E E T I N G would be The last c o m p o n e n t in a message transmission, called the
formatted as shown in Figure 3. client, is a system defined actor used for synchronization,
as will be described later. Note that all four c o m p o n e n t s
0 SCRIPT_ACQ of a message transmission are necessarily acquaintances of
the actor performing the send operation (the "sender").
4 PARTICIPANTS
The sender itself is not automatically a c o m p o n e n t of the
8 POSSIBILITIES resulting message transmission, although it may function as
12 0 the target, message or customer.
16 DURATION
Asynchronous communication is provided by a
20 TIME
SENDC (Send-Continue) operation,
24 COUNT SENDC(target ,message,customer, cl i ent).
The S E N D C operation provides a "fork" capability, as-
Figure 3. Instance Storage for MEETING Actors. ynchronously sending the message to the target. Control
returns immediately to the sender (i.e., the message will
The SCRIPT A C Q field is a required acquaintance varia- not. necessarily have been processed), and the target and
ble which identifies a system defined SCRIPT actor. All sender execute concurrently. In a SENDC operation one
instances of a given type point to a c o m m o n SCRIPT actor can specify all four c o m p o n e n t s of the message transmis-
which identifies the name of the type and the location of sion. If either the customer or client is not specified it
the executable script. Instance storage is allocated from a defaults to the current customer or client, respectively, of
heap, and a garbage collector is used to reclaim the in- the invoking actor.
stance storage of actors which can no longer be accessed
(i.e. those which no other actors have as acquaintances). The system provides three send operations for synch-
Acquaintance variables are separated from the other varia- ronous message communication. For all three, the sender
bles in instance storage to facilitate garbage collection. specifies only the target and message c o m p o n e n t s of the
m e s s a g e transmission. The c u s t o m e r c o m p o n e n t is set
Creating Actor Instances. according to the type of send operation performed. The
A n instance of an actor is created explicitly with a client c o m p o n e n t is always set to the client of the sender.
C R E A T E operation.
SENDR(target,message)

70
 N U L L - the e m p t y actor reference.
A S E N D R ( S e n d - R e p l y ) o p e r a t i o n , provides a s y n c h r o - NOTHING - t h e value which, w h e n u s e d in a R E -
n o u s t r a n s f e r of c o n t r o l similar to t h e p r o c e d u r a l call- TURN s t a t e m e n t , will s u p p r e s s t h e s e n d i n g of a
r e t u r n m e c h a n i s m . T h e s e n d e r serves as t h e c u s t o m e r , a n d reply to t h e c u s t o m e r .
waits for a reply m e s s a g e . The SENDR operation returns
an a c q u a i n t a n c e identifying a reply message. W h e n t h e target a c t o r c o m p l e t e s p r o c e s s i n g of t h e
received m e s s a g e it r e t u r n s either an a c t o r a c q u a i n t a n c e
SEND(target,message) identifying an actor w h i c h c o n s t i t u t e s t h e r e t u r n m e s s a g e ,
a N U L L a c q u a i n t a n c e , or N O T H I N G .
A S E N D operation, is identical to S E N D R except it does
n o t expect a return m e s s a g e , a n d if o n e is generated, it is T h e p r o c e s s i n g p e r f o r m e d by a n actor in r e s p o n s e to
ignored. t h e m e s s a g e s it a c c e p t s is i n d e p e n d e n t of t h e m a n n e r in
w h i c h t h e y are sent. Its p r o c e s s i n g is the s a m e w h e t h e r
SENDE(target,message) m e s s a g e s are sent via S E N D R , S E N D , S E N D E or S E N D C
operations. T h e a c t o r w h i c h s e n d s a m e s s a g e , however,
A S E N D E ( S e n d - E n d ) operation, differs f r o m the o t h e r s m u s t be aware of t h e kind of r e s p o n s e g e n e r a t e d by t h e
in that the invocation of the s e n d e r is t e r m i n a t e d . The target actor w h e n it receives m e s s a g e s of t h e type being
s e n d e r ' s c u r r e n t c u s t o m e r serves as the c u s t o m e r for t h e sent. In particular, it is a n error to s e n d a m e s s a g e via a
m e s s a g e t r a n s m i s s i o n , rather t h a n t h e s e n d e r itself, as in S E N D R o p e r a t i o n if t h e p r o c e s s i n g of that m e s s a g e will
the o t h e r two s y n c h r o n o u s s e n d operations. A s a result, n o t e v e n t u a l l y p r o d u c e a valid reply m e s s a g e .
a n y reply m e s s a g e g e n e r a t e d by this t r a n s m i s s i o n will be
r e t u r n e d directly to this c u s t o m e r . A S E N D E o p e r a t i o n is Set and Get References.
functionally equivalent to T h e code in a n a c t o r ' s script m a y refer to t h e i n s t a n c e
RETURN(SENDR(target ,message ) ) variables of a n o t h e r actor by u s i n g t h e following syntax.
b u t avoids an u n n e c e s s a r y c h a n g e of c o n t e x t s during the
return processing. It is a c o n v e n i e n t m e a n s of f o r w a r d i n g acquaintance->type-name.instance-variable-name
a m e s s a g e to a n o t h e r actor for processing.
T h e m e a n i n g of s u c h a r e f e r e n c e d e p e n d s u p o n w h e r e it
B e t w e e n a n y pair of actors, m e s s a g e s are g u a r a n t e e d a p p e a r s in a s t a t e m e n t . If it is t h e target of an assign-
to be p r o c e s s e d in t h e order in w h i c h t h e y are sent. F o r m e n t , t h e m e a n i n g is that a n e w value is to be placed in
a n y o n e actor the m e s s a g e s are p r o c e s s e d in the order of t h e n a m e d a c t o r ' s i n s t a n c e storage. T h i s is called a s e t
arrival. reference. W h e n t h e e x p r e s s i o n a p p e a r s in a n o t h e r c o n -
text, it is a get reference, a n d m e a n s t h a t the c u r r e n t value
Invoeation of Actors. of t h e variable in t h e n a m e d a c t o r ' s i n s t a n c e s t o r a g e re-
Every message transmission causes a new invocation places t h e e x p r e s s i o n in t h a t context.
of the target actor. If the t a r g e t ' s i n s t a n c e s t o r a g e is cur-
rently residing on s e c o n d a r y storage, it is read into m a i n T h e use of set a n d get r e f e r e n c e s a p p e a r s to violate
memory. If t h e script for actors of t h e t a r g e t ' s type is n o t t h e rule that actors m a y only i n s p e c t a n d m o d i f y their o w n
resident, it is d y n a m i c a l l y loaded. A u t o m a t i c storage is i n s t a n c e storage. H o w e v e r , the violation is only a p p a r e n t .
p r o v i d e d o n a stack, a n d c o n t r o l is t r a n s f e r r e d to t h e T h e s e e x p r e s s i o n s are c o m p i l e d into o b j e c t code w h i c h
a c t o r ' s script. T h e script e x e c u t e s the accept clause corre- ( w h e n n e c e s s a r y ) creates a n d s e n d s o n e of a special set of
s p o n d i n g to the type of t h e m e s s a g e received. m e s s a g e actors to the actor w h i c h o w n s t h e i n s t a n c e stor-
age. T h e s e m e s s a g e s are p r o c e s s e d by a c c e p t c l a u s e s
Special a c q u a i n t a n c e v a l u e s m a y be a c c e s s e d d u r i n g w h i c h are implicitly included in t h e a c t o r ' s script b e c a u s e
execution. T h e s e v a l u e s are c o n s t a n t d u r i n g a n y g i v e n of its i n s t a n c e variables. T h e s e implicit a c c e p t c l a u s e s
i n v o c a t i o n of a n actor, a l t h o u g h t h e y m a y c h a n g e f r o m simply u p d a t e or r e t u r n t h e value of a n i n s t a n c e variable.
o n e invocation to the next. T h e s e special values are: T h u s , the a c t o r itself p e r f o r m s t h e r e q u e s t e d modification
S E L F - the n a m e of the e x e c u t i n g actor instance. or r e t u r n s the r e q u e s t e d value. T h e p a r e n t h e t i c a l refer-
M E S S A G E - t h e n a m e of the actor w h o s e receipt, as ence is to t h e fact t h a t the o b j e c t code m a y directly access
a m e s s a g e , c a u s e d the c u r r e n t invocation. In a n the a c t o r ' s i n s t a n c e s t o r a g e w h e n t h e results of a direct
A C C E P T clause for a " C R E A T E " , M E S S A G E is r e f e r e n c e are i n d i s t i n g u i s h a b l e f r o m t h o s e o b t a i n a b l e b y
the n a m e of a p a r a m e t e r actor. sending a message. Notice that this s y s t e m does n o t in-
C U S T O M E R - the n a m e of t h e actor w h i c h will re- h e r e n t l y provide t h e benefits of " i n f o r m a t i o n hiding", as
ceive a n y reply f r o m t h e c u r r e n t invocation. f o u n d in the a b s t r a c t d a t a type languages. U s e r s w h o wish
C L I E N T - t h e client for the c u r r e n t invocation. to a p p r o x i m a t e t h o s e b e n e f i t s m a y replace t h e implicit

71
 time of the m e e t i n g after receipt of t h e final time interval
MEETING: ACTOR SERIAL; list.
INSTORE
PARTICIPANTS ACQ, Figure 5 s h o w s the actors involved in t h e o p e r a t i o n of
DURATION FIXED,
time interval lists. Such a list c o n s i s t s of a main
TIME FIXED,
COUNT FIXED, TIME INTERVAL LIST actor plus a singly-linked
POSSIBILITIES ACQ; c h a i n of E L E M E N T actors. TIME INTERVAL LIST
DECLARE a c t o r s m u s t h a v e t h e S E R I A L a t t r i b u t e b e c a u s e t h e in-
P ACQ; s t a n c e variables, H E A D a n d C U R R E N T , c a n be m o d i f i e d
ACCEPT('CREATE')
d u r i n g an invocation, a n d t h e r e is no g u a r a n t e e t h a t multi-
DO;
( I n i t i a l i z e PARTICIPANTS and DURATION. ple users won't simultaneously send to a
Set POSSIBILITIES to a TIME INTERVAL LIST TIME INTERVAL LIST. ( N o t e , in c o n t r a s t , t h a t a n
encompassing a l l of the future. - E L E M E N T actor is only k n o w n to t h e a c t o r w h i c h c r e a t e d
I n i t i a l i z e TIME and COUNT to zero.) it. B e c a u s e of t h e p a t t e r n of m e s s a g e s s e n t to E L E M E N T
DO P = SENDR(PARTICIPANTS,CREATE('FIRST'))
actors, it is clear that t h e y do n o t n e e d to be S E R I A L ,
REPEAT SENDR(PARTICIPANTS,CREATE('NEXT'))
WHILE(P 9= NULL); e v e n t h o u g h they, too, m o d i f y their i n s t a n c e storage.)
SENDC(P->PERSON.CALENDAR,SELF);
COUNT = COUNT + I ; In the ACCEPT('CREATE') clause, a
END; TIMEINTERVALLIST initializes its i n s t a n c e storage,
END;
a n d r e t u r n s its o w n n a m e to its c u s t o m e r . U p o n receipt of
ACCEPT('TIME INTERVAL_LIST')
DO; a TIME INTERVAL m e s s a g e , it c r e a t e s a n d c h a i n s a
SEND(POSSIBILITIES,MESSAGE); new ELEMENT actor. ( T h e c h a i n i n g p r o c e s s is a s s i s t e d
COUNT = COUNT - I ; by t h e " C R E A T E " code in t h e E L E M E N T script.) It
IF COUNT = 0 THEN t h e n sets t h e V A L U E a c q u a i n t a n c e of t h e n e w E L E M E N T
DO;
actor to the n a m e of t h e n e w T I M E INTERVAL with
TIME = SENDR(POSSIBILITIES,CREATE('FIRST'))
->TIME INTERVAL.TIME; the s t a t e m e n t :
DO P = SENDR(PARTICIPANTS,CREATE('FIRST'))
REPEAT SENDR(PARTICIPANTS,CREATE('NEXT')) HEAD->ELEMENT.VALUE=MESSAGE;
WHILE(P 9= NULL);
SENDC(P->PERSON.CALENDAR,SELF); A FIRST message causes a TIME INTERVAL L I S T to
END; position its C U R R E N T a c q u a i n t a n c e at t h e H E A D of its
END;
list of E L E M E N T s , a n d t h e n to s e n d itself a N E X T m e s -
END;
END; sage. A N E X T m e s s a g e c a u s e s it to u p d a t e its C U R R E N T
a c q u a i n t a n c e , a n d t h e n to r e t u r n t h e result of a get o p e r a -
Figure 4. Specification for MEETING actors. tion for t h e V A L U E field of its old C U R R E N T ELE-
M E N T with t h e s t a t e m e n t :
accept clauses for the special set a n d get m e s s a g e s with
clauses which explicitly filter or prohibit access to i n s t a n c e RETURN(TEMP->ELEMENT.VALUE);
variables.

Completion of the example. 4. Additional Facilities.

W e n o w r e t u r n to the p r o b l e m of s c h e d u l i n g a m e e t -
ing. With the facilities described so far, we c a n s h o w h o w Actor Names.
s o m e of the actors c o n s t i t u t i n g the solution m i g h t be im- U s e r s of the s y s t e m only k n o w that a n a c q u a i n t a n c e
plemented. variable c o n t a i n s the " n a m e " of an actor with w h i c h it c a n
communicate. T h e internal f o r m of t h e n a m e is n o t re-
First, Figure 4 c o m p l e t e s t h e definition of the M E E T - vealed. The implementation, however, recognizes three
I N G actor w h i c h w a s outlined in Figure 2. T h e overall d i f f e r e n t kinds of n a m e s , local names, global names, a n d
f u n c t i o n i n g of this actor h a s b e e n d e s c r i b e d in section 2, external names. T h e local n a m e of a n actor is simply t h e
and will not be repeated here. Notice, however, a d d r e s s of it's i n s t a n c e storage. It provides direct access
MEETING's u s e of t h e S E N D C o p e r a t i o n to a s y n c h r o - to a n actor, b u t only exists while a n actor is resident in
n o u s l y b r o a d c a s t itself to the C A L E N D A R s of all P E R - m a i n m e m o r y . Local n a m e s are n o t p e r m a n e n t l y assigned,
S O N s o n its list of P A R T I C I P A N T S . T h e first b r o a d c a s t a n d if a n a c t o r m o v e s f r o m o n e n o d e to a n o t h e r or to
o c c u r s in t h e A C C E P T ( ' C R E A T E ' ) clause to r e q u e s t s e c o n d a r y s t o r a g e a n d b a c k to m a i n m e m o r y , it will at
available time intervals. The second one announces the d i f f e r e n t t i m e s h a v e d i f f e r e n t local n a m e s . A global n a m e

72
 TIME INTERVAL LIST: ACTORSERIAL; ELEMENT: ACTOR;
INSTORE INSTORE
HEAD ACQ, FPTR ACQ,
CURRENT ACQ; VALUE ACQ;
DECLARE ACCEPT('CREATE');
TEMP ACQ; DO;
ACCEPT('CREATE') FPTR = MESSAGE;
DO; RETURN(SELF);
HEAD,CURRENT = NULL; END;
RETURN(SELF); END;
END;
ACCEPT('TIME INTERVAL')
DO;
HEAD = CREATE('ELEMENT',HEAD); TIME INTERVAL: ACTOR;
HEAD->ELEMENT.VALUE = MESSAGE; INSTORE
END; TIME FIXED,
ACCEPT('FIRST') DURATION FIXED;
DO; END;
CURRENT = HEAD;
SENDE(SELF,CREATE('NEXT'));
END;
ACCEPT('NEXT') FIRST: ACTOR;
DO; END;
IF CURRENT = NULL THEN RETURN(NULL);
TEMP = CURRENT;
CURRENT = CURRENT->ELEMENT.FPTR;
RETURN(TEMP->ELEMENT.VALUE); NEXT: ACTOR;
END; END;
ACCEPT('TIME INTERVAL LIST')
DO;
(Modify current state by intersecting
with the state of the message.)
END;
END;

Figure 5. Additional actor specifications for meeting problem.

identifies an actor at a n o t h e r node. It is implemented as work, and use of an external name will always result in a
the local name of a system defined actor, of type G L O B - reference to a local actor with that name before it results
AL, which contains the remote n o d e ' s identifier and the in a reference to an actor at a remote node with the same
local name of the actor within that node. An external name.
name acquaintance value may be used to identify an a c t o r
which has b e e n assigned an external name (a character The external name of an actor can be used in scripts
string). It is implemented as the local name of a system as an acquaintance constant which references the actor.

defined actor, of type E X T E R N A L , which contains the F o r example, the phrase

actual character string name. An actor identified by it's

'PERSON.ERIC'->PERSON.CALENDAR
external name may be resident in main m e m o r y , on sec-
ondary storage, or at a n o t h e r node. can be used as a set or get reference to the C A L E N D A R
instance variable of the actor instance E R I C of type PER-
W h e n an actor is created it only has a local name. It SON. A n acquaintance c o n s t a n t may a p p e a r a n y w h e r e in
can be assigned an external name by means of a T I T L E a script that an acquaintance variable is allowed, except as
operation. the target of an assignment operation.

TITLE(acquaintance,external name) Storing Actors.

A c t o r s which have b e e n assigned an external name
where "acquaintance" identifies the actor instance to be
may be saved on secondary storage with a S T O R E opera-
named, and "external n a m e " is a character string of the
tion,
form " t y p e - n a m e . i n s t a n c e - n a m e " . An external name must
be unique within each node. The system does not enforce STORE(acquaintance)
uniqueness of external names t h r o u g h o u t the whole net-

73
Stored actors persist across session boundaries, and exist actor is placed on a F I F O queue of transmissions associat-
until explicitly destroyed. A stored actor is accessible via ed with that actor. This queue supports the guarantee,
it's external name, and will be automatically read into mentioned earlier, that messages will be processed by an
main memory and assigned a local name when referenced. actor in the order in which they are received.

It is not sufficient to store just the specified actor. The second level of s y n c h r o n i z a t i o n is the client.
Take for instance a n a m e d T I M E INTERVAL LIST Clients provide the "join" that corresponds to the "fork"
actor which uses a linked list of u n n a m e d E L E M E N T capability given by send-continue (SENDC). C L I E N T is
actors to identify the elements of the list. One could not a system actor type. W h e n a n o n - N U L L client actor is
store just the list actor, but would have to also include the specified for a transmission started by a SENDC opera-
list of element actors. Because of this, a STORE opera- tion, it keeps track of the a s y n c h r o n o u s execution p a t h
tion results in storing the following collection of actors. started by that SENDC. In particular, it keeps a count of
1. The specified named actor. such execution paths, incrementing the count for each new
2. All u n n a m e d acquaintances accessible from that actor SENDC with that client, and decrementing the count when
without an intervening named actor. each path terminates. W h e n the count reaches zero--i.e.,
3. For each accessible named actor, a system E X T E R N A L all a s y n c h r o n o u s execution paths b e g u n with t h a t client
actor containing the actor's external name. have ended--the client actor initiates a transmission with
The collection of actors is stored in the form of a single target and message actors which were specified at the
variable length record called a stored actor record. creation of the client.

Remote Actor Invocations. • . °

If the target of a message transmission identifies an MYCLIENT = CREATECLIENT(SELF,

actor at a remote node, then a system R E M O T E actor is CREATE('RESUME'));
invoked in place of the target. The R E M O T E actor inter- SENDC(ACTOR1,MESSAGE1,,MYCLIENT);
SENDC(ACTOR2,MESSAGE2,,MYCLIENT);
faces with the network to cause the remote invocation of
RETURN(NOTHING);
the target actor. The message actor is either moved to the
remote node or a G L O B A L actor identifying the me~sage ACCEPT('RESUME')
is sent in its place. At the remote node the G L O B A L
actor is interpreted as a global name acquaintance.
Figure 6. Using Clients for Synchronization.
W h e n an actor is moved to another node, it is done by
forming a network actor record. A network actor record is
In the example in Figure 6, M Y C L I E N T is a client
the same as a stored actor record, except that the originat-
actor whose target acquaintance contains the name of the
ing actor need not be named. Additionally, the acquain-
actor which created it (because of the reference to SELF),
tances identified by local names, can either be included in
and whose message acquaintance is an actor of type RE-
the record or be represented by system G L O B A L actors.
SUME. Before control is relinquished by the R E T U R N
A network actor record is a portable form of an actor
statement, the two SENDC operations will have caused the
which can be sent around the network. U p o n arrival at a
client's count to be set at 2. W h e n the processing initiated
node it is read into memory by the same m e c h a n i s m used
by MESSAGE1 and M E S S A G E 2 has been completed, the
to read stored actor records.
client's count will have been decremented to zero. The
Synchronization. client will then send the R E S U M E actor as a message to
Several m e c h a n i s m s are provided for synchronizing the actor which created it. Notice, finally, that the target
actor execution. Together, these mechanisms constitute a actor has an accept clause for messages of type R E S U M E ;
general architecture within which any desired synchroniza- this is the point at which the "join" operation occurs.
tion control structure can be built.
Activities are provided at the third level of synchroni-
At the lowest level, actors can be marked non-serlal or zation. T h e y are similar to clients in that they can monitor
serial. A message transmission to a non-serial actor can the progress of a s y n c h r o n o u s execution paths, and they
cause the invocation of that actor to occur immediately, allow the specification of a transmission which is to occur
even when the actor is already executing (with a message at the termination of those paths. In addition, activities
from a separate transmission). In order to support such may be cancelled and are capable of being hierarchically
concurrent processing, the code in all actor scripts is re- nested within one another. If an actor executing as part of
entrant. T r a n s m i s s i o n s to non-serial actors are never one activity issues a SENDC operation with another activi-
queued. On the other hand, a transmission to a busy serial ty specified as client, then the transmission issued at the

74
completion of the child activity is considered to be part of ACTIVITY: ACTORSERIAL;
the parent activity. Parent activities may execute concur- INSTORE
rently with their children, but they are never considered TARGET ACQ,
MSG ACQ,
complete until all of their children have either terminated
ORIGINATOR ACQ,
or been cancelled. PARENT ACTIVITY ACQ,
MY CLIENT ACQ,
• ° °
MY WORKIS DONEBIT(1),
ACTIVITYI = CREATE_ACTIVITY(SELF, CHILD COUNTFIXED;
CREATE('RESUMEI')); ACCEPT(TCREATE' )
ACTIVITY2 = CREATE_ACTIVITY(SELF, DO;
CREATE('RESUME2')); ( I n i t i a l i z e the TARGETand MSG acquaintances.
SENDC(ACTORI,MESSAGEI,,ACTIVITYI); Set PARENTACTIVITY to the name of the current
SENDC(ACTOR2,MESSAGE2,,ACTIVITY2); a c t i v i t y , or NULL i f there is none.)
IF PARENTACTIVITY 9= NULL THEN
ACCEPT('RESUMEI') SEND(PARENT ACTIVITY,
DO; CREATE('YOU HAVE A CHILD'));
CANCEL(ACTIVITY2); ORIGINATOR = CUSTOMER; - -
MY WORKIS DONE = 'O'B;
END; CHILD COUNT = O;
ACCEPT('RESUME2') MY CLIENT = CREATECLIENT(SELF,
DO; - CREATE('YOUR WORKIS DONE ));
CANCEL(ACTIVITYI); RETURN(MY_CLIENT);
END;
END; ACCEPT('YOU HAVE A CHILD')
CHILD COUNT = CHILD COUNT+i;
ACCEPT('YOU_LOST_A_CHILD')
Figure 7. Using Activities for Synchronization. DO;
CHILD COUNT = CHILD COUNT-I;
IF CHILD COUNT = 0 & MY WORKIS DONETHEN
An example of the use to which the ability to cancel DO;
IF PARENTACTIVITY ~= NULL THEN
activities may be put appears in Figure 7. When either
SEND(PARENT ACTIVITY,
activity completes, the first action of the "join" code is to CREATET'YOU LOST A CHILD'));
cancel the other activity. (Note that the join for the can- SENDC(TARGET,MSG,ORIGINATOR,NULL);
celled activity will never be executed.) If ACTOR1 and END;
ACTOR2 were, for example, trying to produce the same END;
ACCEPT('YOUR_WORK IS DONE')
result using different algorithms, this type of control struc-
DO;
ture would allow the cancellation of the losing algorithm as MY WORKIS DONE = ' i ' B ;
soon as the other one succeeds. IF-CHILD COUNT = 0 THEN
DO;
The activity mechanism is entirely implemented with IF PARENTACTIVITY 4= NULL THEN
the system actor type, ACTIVITY. The script for activity SEND(PARENT ACTIVITY,
CREATE('YOU LOST A CHILD'));
actors is illustrated in Figure 8. The instance variables of
SENDC(TARGET,MSG,ORIGINATOR,NULL);
activity actors include a fixed point child count, as well as END;
target, message, and parent activity. The child count and END;
the parent activity acquaintance form the basis for the END;
ability to nest activities. Every new activity becomes a
Figure 8. Definition of the ACTIVITY actor.
child of the activity under which it is created. Part of the
creation process for activities involves sending a tions, the client sends a YOUR WORK IS DONE
YOU HAVE A CHILD message to the parent, caus- message to the activity actor which created it. When this
ing it to increment its child count. When an activity and happens, the activity will terminate as soon as it detects
all of its children have finished, it transmits its message that its child count has reached zero.
acquaintance to the target, and sends a
YOU LOST A CHILD message to its parent. The
parent, in turn, decrements its child count. S. Performance Considerations.

When created, each activity actor creates a client It must be possible to develop actor-based applications
actor to manage its own actor invocations (as opposed to which meet acceptable levels of performance, i.e., per-
those of its children). Upon completion of these invoca- formance comparable to a direct implementation in a high

75
level language. The following summarizes those aspects of sender, and for SENDE operations in replaces the
the actor programming system directed at performance. sender (the sender's invocation is terminated). The
net effect is that the target actor invocation occurs
1. Actor scripts are compiled, rather than interpreted. just above the customer actor invocation, as if the
Compiling will generally yield superior performance. target had been called by the customer. This allows a
The ability to define larger actors, of a size compara- message to be returned to the customer via a normal
ble to a procedure, allows one to capitalize fully on procedural return statement.
compiler optimization techniques.
6. The process of storing an actor on secondary storage,
2. Messages are passed by reference, and are copied only and subsequently reading it back into main memory is
when it is necessary for transmission across a network. a potential performance problem. The process in-
This is particularly important in an actor system where volves a potentially large collection of actors. The
messages are actors and can be large. Actors, such as format of the actors within a stored actor record is
the MEETING actor in the example, frequently pass kept the same as in main memory, with acquaintances
themselves to an acquaintance as a message, even converted to offsets from the beginning of the record.
though a much smaller message could have sufficed. This makes it possible, when reading a stored actor, to
process the entire record as a unit, and avoid separate
3. Symbolic references to actors (external names) are
allocations for each component actor. The stored
resolved to direct memory addresses. This avoids
actor record is read directly into a block of storage
having to resolve symbolic names on every reference.
within the area used for instance storage. A single
In addition, a hash table is used to provide quick reso-
pass is made over the the record to convert the ac-
lution of external names of actors already resident in
quaintance record offsets to local names. In addition,
main memory.
SCRIPT actors are not stored. Instead, their names
are placed at the end of the stored actor record, and
4. An executing actor-based application will typically cre-
they are recreated when the record in read. External
ate a large number of actors. Thus, actor instances
name acquaintances are intentionally not resolved
must be inexpensive to create and have a minimal
when a stored actor is read. The send mechanism
amount of space overhead. The processing cost of
dynamically resolves the external name acquaintances
creating an actor is essentially the cost of allocating a
upon first use, thus reestablishing connections to
structure in an area. The storage costs for an actor
named actors which were severed during the storing
can be as small as 8 bytes, a 4 byte header and 4
process. A beneficial by-product of storing and read-
bytes for the obligatory script acquaintance.
ing an actor is that the actor and its unnamed acquain-
5. The large number of send operations which will be tances become physically adjacent in main memory.
performed in a typical application make the cost of a
send operation a significant factor in overall perform-
6. Applications.
ance. Some send operations will be unavoidably ex-
pensive, requiring, allocation of a stack, resolving ex- Part of the motivation for building the actor system is
ternal names, network transmissions, dynamic loading to explore the usefulness of the actor model of program-
of an actor's instance storage from secondary storage, ming for building substantial applications. This explora-
and dynamic loading of a script. The majority of send tion naturally involves the programming of actual applica-
operations, however, will be synchronous (SEND, tions.
SENDR, SENDE) transmissions where both the target
actor's instance storage and script are already resident An application is a subsystem of actors communicating
in main memory. The system design strives to make with each other. The application designer must approach
these transmissions as efficient as a normal procedure his task differently than if he were using a traditional pro-
call. When the send mechanism is invoked the target gramming system. For example, he cannot use global data
acquaintance is the address of the target's instance structures, since actors provide none. He must decompose
storage, and the first acquaintance in that instance his problem into active entities--which he then implements
storage block points to a SCRIPT actor containing the as actors--rather than passive data structures operated
address of the script to be executed. The send mecha- upon by arbitrary control structures. The interfaces
nism can simply transfer control to the identified among these entities must be well-defined. Distributed
script. The script runs on the current stack, i.e. the applications become easier to define, since distribution is
stack of the sending actor invocation. For SEND and built into the actor model. Asynchrony is much more
SENDR operations it executes immediately above the accessible than in other systems, and the designer should

76
incorporate it in intelligent ways. As the designer gains activation of a new window forces a "focus shift" on the
experience with the actor model, he is rewarded with in- part of the user. Individual SBA windows are controlled
creased ease in developing and implementing system struc- by instances of a WINDOW actor type. Each one can
tures for his applications. change its own name, size, color, border, and height with
respect to other windows. A window can also initiate
We summarize some of the applications built, and office applications, manipulate multiple graphical images
being built, using actors. belonging to the applications, and scroll over these images,
all in response to user commands. The window actors
Our first application was an implementation of the communicate with an actor of type SCREEN by sending it
OMEGA knowledge representation system (Hewitt, Attar- PICTURE messages. The screen actor manipulates the
di, and Simi (1980)). OMEGA represents knowledge as a multiple pictures of windows, creating, moving, and over-
network of "descriptions". At the lowest level, descrip- lapping them on command; it also notifies the window
tions represent the objects of the world being modelled, actors of user activity at the terminal, by sending modified
and the links in the network represent inheritance and PICTURE actors.
attribution relationships among those objects. The more
interesting aspect of OMEGA is that descriptions may also The SBA window system provides a unified applica-
represent axioms which further describe the semantics of tion development and execution environment at an office
the world being modelled. workstation. Additional applications, also built of actors,
operate within the window environment. These applica-
The implemented system provides a language in which tions are "graphical" in the sense that they communicate
OMEGA statements and requests can be entered. State- with WINDOW actors about their status by sending and
ments are transformed into their corresponding descrip-
receiving PICTURE messages. They include:
tions and merged with the network of existing descriptions. SBA tables and files which .support Query-by-
Requests explore the inheritance and attribution links, Example operations, and whose underlying relation-
under the control of the axioms in existence, and yield al access method was simulated by an O M E G A
information to the user. Some of the description types
network,
supported, along with examples of the description lan- - SBA forms,
guage, are given below: - a personal calendar,
Atomic - d 0 h n - a continuously running digital clock, and
I n s t a n c e - (a c h i l d ) - a lightpen-operated pocket calculator.
With-attribution - ( w i t h sex real e)
Inheritance- (is John (a child (with sex male))) We must not forget that one of the more important
Variable - =x applications of actors to date has been the implementation
Implication - (=> (is =x (a child (with sex of the actor system itself. The use of actors to implement
m a l e ) ) ) ( i s = x (a b o y ) ) ) clients, activities, scripts, directories, loaders, and names,
testifies to the generality of the actor programming model.
The implementation represents each description type
as an actor type; actor instances, therefore, represent indi-
vidual descriptions. The acquaintances of a description 7. Summary and Status.
actor include the other descriptions linked to it in the
semantic network. Additional actors provide such func- The actor-based programming system takes the formal
tions as user communication, input parsing, output format- theory of actors and adapts it for use as a language and
ting, and triggering of user-supplied axioms. Altogether, system for developing applications. Whereas actor systems
about forty actor types, with scripts ranging in size from have previously been used only in artificial intelligence
two lines to four-hundred lines of actor code, were re- research, they can now be employed in other areas. In
quired for the implementation. During an OMEGA ses- particular, we propose to use ours for programming dis-
sion, thousands of actor instances may be in existence at tributed business applications. An application is imple-
one time. mented as a collection of independently executing actors
communicating by messages. They can be distributed over
A second actor application is an end-user window a network of computing nodes, and permanently stored on
interface to the SBA system. The interface gives the user disk. A naming architecture allows actors to communicate
simultaneous access to multiple overlapping windows on in a uniform way regardless of their location or status.
his terminal screen. All windows are active at all times;
this contrasts with systems - like Smalltalk - in which the Actor types are defined through a PL/I-like language
user interacts with a single "active" window, and in which which specifies both a storage area to be associated with

77
the actor and its behavior in response to the messages it Acknowledgements.
accepts. This behavior may involve changing the state of We wish to t h a n k Carl Hewitt for many long and
its instance storage area, creating other actor instances, exciting discussions of the actor formalism and the descrip-
initiating communication with its actor acquaintances, and tion system O M E G A , especially during his stay at the IBM
returning a message to the actor which caused it to be T. J. Watson Research Center in the summer of 1980. We
invoked. Mechanisms are provided for synchronizing also thank John Lucassen for his energetic work during the
concurrently executing actors. early stages of the actor system implementation, and Ken
Niebuhr, the other member of the SBA group, for his
While the system retains the desirable properties of insight during many discussions.
actors, performance has been a primary concern, and we
have been careful to avoid the inefficiencies usually found References.
in object-oriented message-passing systems. The size of
an actor specification can vary from two lines to hundreds Baker, H. G., Jr. (1978) Actor Systems For Real-Time
of lines of PL/I-like code, and is compiled with an optim- Computation, M.I.T. Ph.D. Thesis. Laboratory
izing compiler. Messages are passed by reference; and are of Computer Science Technical Report
only copied when transported across the network. Names M I T / L C S / T R - 197.
of acquaintance actors are dynamically bound to direct Birtwistle, Dahl, Myhrhaug, and Nygaard (1973) SlMULA
memory references upon first use. Begin, Auerbach.
Byrd, R. J. (1980) "Macros and Coding Conventions for
Status. SBA Boxes," SBA project memo.
The prototype processor for the actor language was de Jong, S. P. (1980) "The System for Business Automa-
built using an existing optimizing compiler for a subset of tion (SBA): A Unified Application Development
the P L / I language together with the standard P L / I macro System," in IFIPS Congress 80 Proceedings,
preprocessor (I.B.M. (1976)). Syntactic and semantic North Holland Publishing Company.
de Jong, S. P., and R. J. Byrd (1980) "Intelligent Forms
limitations imposed by the macro preprocessor resulted in
Creation in the System for Business Automation
the implemented language differing somewhat from the
(SBA)," I.B.M. Research Report RC 8529.
descriptions given in this paper (see Byrd (1980)). Con-
Hewitt, C. (1977) "Viewing Control Structures as Patterns
tinued development of the actor system should include the of Passing Messages," in Artificial Intelligence
implementation of a compiler for the actor language. Vol. 8, pp. 323-364.
Hewitt, C. (1980) "The Apiary Network Architecture for
Some of the described language features, such as the Knowledgeable Systems," M.I.T. AI Lab Memo.
ability to cancel activities, have not yet been implemented. Hewitt, C., G. Attardi, and M. Simi (1980) "Knowledge
The concept of inheritance, which is similar the Smalltalk Embedding in the Description System O M E -
notion of superclass, is needed, as well as a mechanism by GA," in Proceedings of the First National Annual
which an actor can delegate the handling of a message to Conference on Artificial Intelligence American
another actor. The information hiding properties of the Association for Artificial Intelligence, August
abstract data type languages, such as CLU, should be 1980.
made available. The serial/non-serial attribute could be I.B.M. (1976) OS P L / I Checkout and Optimizing Compi-
made a function of the message type being processed, and lers: Language Reference Manual, I.B.M. form
an actor's instance storage could be allowed to dynamical- GC33-0009.
ly vary in size. Ingalls, D. H. H. (1978) "The Smalltalk-76 Programming
System: Design and Implementation," in Confer-
The existing prototype implementation is for a single ence Record of the Fifth Annual ACM Symposium
on Principles of Programming Languages, pp. 9-
actor node in a V M / 3 7 0 virtual machine. It is being ex-
16.
tended to multiple actor nodes residing in a network of
Lieberman, H. (1981) "A Preview of Act 1," M.I.T. AI
virtual machines. This will simulate the intended process-
Lab Memo 625.
ing configuration of a local network of small computers,
Liskov, B., A. Snyder, R. Atkinson, and C. Schaffert
and allow experimentation with distributed actor applica- (1977) "Abstraction Mechanisms in C L U , " in
tions. This will be a vehicle for conducting research on Communications of the ACM, Vol. 20, no. 8, pp.
the difficult problems confronting distributed applications, 564-576.
including deadlock detection/prevention, crash recovery, Zloof, M. M., and S. P. de Jong (1977) "The System for
and distributed garbage collection. An actor-based system Business Automation (SBA): Programming Lan-
should provide the potential for unique and interesting guage," in Communications of the ACM, Vol. 20,
solutions to problems in these areas. no. 6, pp. 267-280.

78