43 Years of Actors: a Taxonomy of Actor Models and Their Key Properties
Total Page：16
File Type：pdf, Size：1020Kb
43 Years of Actors: A Taxonomy of Actor Models and Their Key Properties Joeri De Koster Tom Van Cutsem Wolfgang De Meuter Vrije Universiteit Brussel Nokia Bell Labs Vrije Universiteit Brussel Pleinlaan 2 Copernicuslaan 50 Pleinlaan 2 1050 Elsene, Belgium 2018 Antwerp, Belgium 1050 Elsene, Belgium [email protected] tom.van cutsem@nokia-bell- [email protected] labs.com Abstract languages as well as industrial strength programming lan- The Actor Model is a message passing concurrency model guages and libraries. that was originally proposed by Hewitt et al. in 1973. It is Because actors are often strictly isolated software enti- now 43 years later and since then researchers have explored ties and because of the asynchronous nature of its communi- a plethora of variations on this model. This paper presents cation mechanism, they avoid common concurrency issues a history of the Actor Model throughout those years. The such as low-level data races and deadlocks by design. Over goal of this paper is not to provide an exhaustive overview the years these properties have made the Actor Model into an of every actor system in existence but rather to give an interesting concurrency model to be used both for exploiting overview of some of the exemplar languages and libraries fine-grained concurrency in massively parallel workstations that influenced the design and rationale of other actor sys- as well as for exploiting more coarse-grained concurrency in tems throughout those years. This paper therefore shows that a distributed setting. More than 40 years later, there now ex- most actor systems can be roughly classified into four fam- ist bountiful implementations of the Actor Model in various ilies, namely: Classic Actors, Active Objects, Processes and programming languages and libraries. Each of these imple- Communicating Event-Loops. This paper also defines the mentations defines a slightly different flavour of the Actor Isolated Turn Principle as a unifying principle across those Model. This paper has three main contributions. four families. Additionally this paper lists some of the key Firstly, because of all the variations on the Actor Model, properties along which actor systems can be evaluated and over the years researchers have employed different terms formulates some general insights about the design and ratio- to describe the different concepts that make up the Actor nale of the different actor families across those dimensions. Model. One of the contributions of this paper is to define a common nomenclature for each of the key concepts of Categories and Subject Descriptors D.3.2 [Language the Actor Model. While a precise definition would require a Classifications]: Concurrent, distributed, and parallel lan- formal grounding, for this work, we currently limit ourselves guages; D.1.3 [Concurrent Programming]: Parallel pro- to an informal definition for each of the terms and concepts. gramming A list of terms and their definitions can be found under General Terms Languages, Theory Section 2. Secondly, while each of these variations on the Actor Keywords Actor Model, Concurrency Model builds on top of a common substrate, in this paper 1. Introduction we identify and define four broad families along which each actor system can be categorised. Namely: Classic Actors, The Actor Model is a concurrency model that was originally Active Objects, Processes and Communicating Event-Loops. proposed by Hewitt et al. in 1973 [13]. Since then it has been We provide an overview of the history of actor systems and used as the model of concurrency for both academic research a definition for each of the different families along which every actor system can be categorised in Section 3. Thirdly, categorising an actor system along one of these four families gives some indication of the properties and structure of that actor system. However, the actual properties of that system still remain largely dependent on the specific implementation of the actor system. We present a number of properties along which an actor system can be evaluated with respect to that actor’s interface and state. This continues in Section 4 and formulate some general insights about the until the inbox is empty after which the actor goes to an idle design and rationale of the different actor families across state until a new message arrives in its inbox. those dimensions. actor system An actor system is a language or library that implements the Actor Model as an abstraction for concur- 2. Terminology and Definitions rency. Every actor system enables the creation and concur- Before we further delve into the history of the Actor Model rent execution of actors. we must first start by establishing a common terminology by which we can denominate the different concepts defined by 3. History of Actor Systems an actor system. In this section we give an overview of the The Actor Model was originally proposed by Hewitt et different terms used for each of the key concepts found in al. in 1973 [13] in the context of artificial intelligence re- every actor system. We also provide an informal definition search at MIT. The original goal was to have a program- for each of these concepts. In the following sections we will ming model for safely exploiting concurrency in distributed mix these terms depending on the language being discussed. workstations. The problem domain was modelling paral- message, envelope, event, request A message is the unit lel communication based problem solvers. In October of of communication between different actors. A message is a 1975 Hewitt and Smith [12] wrote a primer on a language combination of an identifier that defines the type of message called PLASMA, the first language implementation of the and a payload that contains additional information sent with Actor Model. In PLASMA, actors communicate with each that message. If one actor sends a message to another actor, other via message passing which consists of sending a re- that message is stored in the latter actor’s inbox, independent quest from one actor (called the messenger) to another ac- of the recipient actor’s current processing state. tor (called the target). The request and a reference to the messenger are packaged as an envelope and put into the in- inbox, mailbox, message queue, event queue The inbox box of the target actor (request: message; reply-to: of an actor stores an ordered set of messages received by messenger). Given that envelope, the behaviour of the tar- that actor. While the inbox defines the order in which the get actor then specifies how the computation continues with messages were received, that does not necessarily imply that respect to the request. The messenger is typically used as the those messages are processed by that actor in that order. reply address to which a reply to the request should be sent. turn, epoch, step A turn is defined as the processing of a The simplest control structure that uses this request-reply single message by an actor. In other words, a turn defines pattern in most programming languages is the procedure call the process of an actor taking a message from its inbox and and return. A recursive implementation of factorial written processing that message to completion. in PLASMA is given in Listing 1. (factorial ≡ interface At any given point in time, an actor’s interface (≡> [=n] defines the list and types of messages it understands. An (rules n actor can only process incoming messages that fit this in- (≡> 1 terface. For some actor systems this interface is fixed while 1) other actor systems allow an actor to change its interface, (≡> (> 1) thus allowing it to process different types of messages at dif- (n * (factorial <= (n - 1))))))) ferent points in time. Listing 1. Factorial function written in PLASMA. state At any given point in time, we define an actor’s state In this example factorial is defined to be an actor of which as all the state that is synchronously accessible by that actor the behaviour matches the requests of incoming envelopes (i. e. state that can be read or written without blocking its with one element which will be called n. The rules for thread of control). Depending on the implementation, that n are, if it is 1, then we send back 1 to the messenger state can be mutable or immutable, and isolated or shared of the envelope. Note that this is done implicitly. If it is between actors. greater than 1, we send a message to the factorial actor to recursively compute the factorial of (n - 1). The Actor behaviour A behaviour is a common term to denote the Model only became more widely regarded as a general- combination of an actor’s interface and its state. Some actor purpose concurrency model when it was recast in terms of systems enable an actor to modify its entire behaviour in one three simple primitives by Gul Agha [1, 2] in 1986. Agha single operation. redefined the Actor Model in terms of three basic actor actor, active object, activity, vat, grain An actor can be primitives: create, send and become. His vision of the Actor defined as a four-tuple: an execution context, an inbox, an Model laid the foundations for a host of different other interface and its state. An actor perpetually takes messages actor systems and these three primitives can still be found from its inbox and processes them in a new execution context in various modern actor languages and libraries today. This section gives an overview of a small but representa- Classic Actor Model tive selection of the ancestry of actor systems from 1973 un- The Classic Actor Model formalises the Actor Model in til today. We classify the different actor languages into four terms of three primitives: create, send and become.