Why has the actor
model not succeeded?
Be not afraid of greatness.
Some are born great,
some achieve greatness,
and some have greatness thrust upon Ďem.
[Twelfth Night, II.v]
To this day, the actor model has
not yet achieved greatness or wide recognition and use, and it is unknown
whether it may ever have greatness thrust upon it. What are the reasons
for its minor role to this day? Indeed, as yet there has not been a complete
implementation of the theoretical actor model. Several useable actor based
languages have been written, but they tend to include features which extend
the functionality to some extent.
The actor model or paradigm was
created by Carl Hewitt in the early 1970ís. During this time there was
a veritable explosion of programming language development, as the power
and capability of computers increased. It became apparent as the desire
for larger and more complex software increased that imperative languages
broke down as the size grew beyond a certain point.
The Object-Orientated Model
The development of the object model,
and object orientated programming began with Simula, but the first true
OO language was Smalltalk in its third incarnation in 1976. Later languages
such as C++ were developed and became extremely popular, and are used for
a wide variety of applications today. One of the factors which drove the
development of the new paradigms is artificial intelligence (AI) research.
The actor model was created for use in AI and in parallel or distributed
systems, for it was found that AI required heavy computation. The model
lent itself to open systems, which could be continually evolving.
One of the reasons for the object modelís success is
that it dealt with the structure of programs in a fundamentally different
way. The problem was broken down using abstraction into the objects which
it contained, their properties and the relationships between them. Encapsulation
hid the implementation of these properties from the user of the objects,
and the modularity of this structure made it easier to understand. Hierarchy
(or inheritance, to a more specialist degree) allowed the reuse of common
code among particular objects having the same general characteristics.
Other features such as typing, concurrency and persistence were developed
which aided the production of more robust and versatile code.
These new ways of examining the
problem provided programmers with the ability to break down a complex problem
into simpler concepts. This meant much larger software could be written,
to take advantage of the new hardware technology being developed. As greater
demands were made by new applications of software, parallel systems were
developed for the processing power they offered. Parallel systems were
expensive, and it was found that distributed systems, where two or more
smaller desktop computers were linked together in order to share processing
power and data, were more cost effective.
The abstract model of a distributed
system requires comprehensive, secure communications facilities for the
system to operate efficiently. Message passing is used because it can provide
communication with remote processors, wherever they may be. Due to its
distributed nature, the time taken for transmission of messages can vary,
which means that synchronous communication is very inefficient in this
In this respect the actor model seems ideally suited
for use with distributed systems. It communicates exclusively using message
passing, and is completely asynchronous. So why has the actor model been
unsuccessful in this area for which it was designed?
When the actor model was first proposed,
the development of distributed networks was in its infancy. The conceptual
model of actors is easy to understand as it allows state to be directly
expressed. Also the only side effects of an actor are to send communications
and to set a new behaviour. The simplicity of this model suggests that
it would make programming for a distributed system simpler, but there proved
to be difficulties associated with its implementation.
Problems of the Actor Model
The actor model has no direct notion
of inheritance or hierarchy, which means it is time consuming and confusing
to program actors with trends of common behaviour. Actors allow abstraction
of the concepts, but in almost all non-trivial programs there will be many
kinds of abstraction. Actors encompass the ideas of modularity and encapsulation
though, because an actor is self contained and can be considered atomic.
There are also issues more fundamental to the architecture
which prove hard to realise. One of the key features of actors, their ability
to create other actors as part of their behaviour, has the potential to
dramatically change the state of the system at any particular time. The
decisions of where to store and execute newly created actors is important
to overall performance, and will require records to be kept of what is
executing and where. If the system is very distributed, (e.g. the Internet)
then the communications involved between different locations must also
be noted, as they will affect performance drastically between remote locations.
Another problem is behaviour replacement.
The behaviour is dynamic, and very difficult to perform using a static
language (e.g. C). Static analysis cannot support reflection, or reconfiguration
of the runtime system. The fact that the behaviour can be altered also
makes optimisation of the program very difficult. The notion of weak fairness
in guaranteeing delivery of messages requires unbounded mailboxes. This
implies some form of infinite stack or pointer structure, but it cannot
be assumed that this is available in all architectures. The memory requirements
of object-orientated programs can usually be determined before runtime.
The idea of asynchronous message
passing may cause problems with certain programs or algorithms. For
example, manipulation of a stack-like structure using asynchronous message
passing could be problematic if the messages do not arrive in the correct
order. When an actor requires a reply message from another actor, it is
known as an insensitive actor, and will not process any further messages
in its mail queue until it receives that reply. While being conceptually
elegant, this is hard to implement efficiently, because the actorís one
message queue must handle both the reply message and new messages from
Object-orientated programs also rely on message passing
to a degree, but with the use of strong typing and static resolving, the
number of dynamic method invocations requiring a message can be reduced
substantially. This is much more difficult using actors. The actor model
also uses many more actors than the object model uses objects for equivalent
functionality, because in the actor model even an integer is represented
as an actor.
The problems outlined above are
some of the inherent difficulties associated with the actor model. When
the model was first proposed, the knowledge of distributed and parallel
systems was not advanced enough to be able to adapt the conceptual model
to an efficient implementation of an actor language. The actual languages
based on actors were adapted to make their organisation easier. In recent
years research has led to more efficient methods for implementing the model,
and the other driving force is that the nature and knowledge of networks
and systems today has greatly expanded. The growth of the Internet, the
truly global distributed network, must use asynchronous message passing,
due to the very remote locations of processors and the time delays inherent
in transmission. Mobile computing as a technology and a way of working
has also grown from nothing during the 80ís and 90ís. More recent studies
have shown that the actor model at its current stage of development can
now be made efficient to the necessary level for the todayís requirements.
 G.Agha, C. Houck and R. Panwar. Distributed Execution
of Actor Programs. University of Illinois.
 G. Agha. An Overview of Actor Languages. MIT, Cambridge,
Mass. June 1986