Actor model implementation

Last updated

In computer science, Actor model implementation concerns implementation issues for the Actor model.

Contents

Cosmic Cube

The Caltech Cosmic Cube was developed by Chuck Seitz et al. at Caltech providing architectural support for Actor systems. A significant difference between the Cosmic Cube and most other parallel processors is that this multiple instruction multiple-data machine uses message passing instead of shared variables for communication between concurrent processes. This computational model is reflected in the hardware structure and operating system, and is also the explicit message passing communication seen by the programmer. According to Seitz [1985]:

It was a premise of the Cosmic Cube experiment that the internode communication should scale well to very large numbers of nodes. A direct network like the hypercube satisfies this requirement, with respect to both the aggregate bandwidth achieved across the many concurrent communication channels and the feasibility of the implementation. The hypercube is actually a distributed variant of an indirect logarithmic switching network like the Omega or banyan networks: the kind that might be used in shared-storage organizations. With the hypercube, however, communication paths traverse different numbers of channels and so exhibit different latencies. It is possible, therefore, to take advantage of communication locality in placing processes in nodes.

J–Machine

The J–Machine was developed by Bill Dally et al. at MIT providing architectural support suitable for Actors. This included the following:

Concurrent Smalltalk (which can be modeled using Actors) was developed to program the J Machine.

Prototype Actor Programming Language

Hewitt [2006] presented a prototype Actor programming language in the sense that it directly expresses important aspects of the behavior of Actors. Messages are expressed in XML using the notation :<tag>[<element>1 ... <element>] for

<<tag>><element>1 ... <element>n<”/<tag>>

The semantics of the programming language are defined by defining each program construct as an Actor with its own behavior. Execution is modeled by having Eval messages passed among program constructs during execution.

Environment Actors

Each Eval message has the address of an Actor that acts as an environment with the bindings of program identifiers. Environment Actors are immutable, i.e., they do not change. When Request[Bind[identifier value] customer] is received by an Actor Environment, a new environment Actor is created such that when the new environment Actor receives Request[Lookup[identifier’] customer’] then if identifier is the same as identifier’ send customer’Returned[value], else send Environment Request[Lookup[identifier’] customer’]. The above builds on an Actor EmptyEnvironment which when it receives Request[Lookup[identifier] customer], sends customerThrown[NotFound[identifier]]. When it receives a Bind request EmptyEnvironment acts like Environment above.

Expressions

The prototype programming language has expressions of the following kinds:

<identifier>
When Request[Eval[environment] customer] is received, send environmentRequest[Lookup[<identifier>] customer]
send<recipient><communication>
When Request[Eval[environment] customer] is received, send <recipient>Request[Eval[environment] evalCustomer1] where evalCustomer1 is a new Actor such that
when evalCustomer1 receives the communication Returned[theRecipient], then send <communication>
Request[Eval[environment] evalCustomer2] where evalCustomer2 is a new actor such that
when evalCustomer2 receives the communication Returned[theCommunication], then send theRecipienttheCommunication.
<recipient>.<message>
When Request[Eval[environment] customer] is received, send <recipient>Request[Eval[environment] evalCustomer1] such that
when evalCustomer1 receives the communication Returned[theRecipient], then send <message>Request[Eval[environment] evalCustomer2] such that
when evalCustomer2 receives the communication Returned[theMessage], then send theRecipient
Request[theMessage customer]
receiver ... <pattern>i<expression>i ...
When Request[Eval[environment] customer] is received, send customer a new actor theReceiver such that
when theReceiver receives a communication com, then create a new bindingCustomer and send environment
Request[Bind[<pattern>i com] bindingCustomer] and
if bindingCustomer receives Returned[environment’], send <expression>i
Request[Eval[environment’]]
otherwise if bindingCustomer receives Thrown[...], try <pattern>i+1
behavior ... <pattern>i<expression>i ...
When Request[Eval[environment] customer] is received, send customer a new actor theReceiver such that
when theReceiver receives Request[message customer’], then create a new bindingCustomer and send environment
Request[bind[<pattern>i message] customer’] and
  1. if bindingCustomer receives Returned[environment’], send <expression>i
    Request[Eval[environment’] customer’]
  2. otherwise if bindingCustomer receives Thrown[...], try <pattern>i+1
{<expression>1, <expression>2}
When Request[Eval[environment] customer] is received, send <expression>1Request[Eval[environment]] and concurrently send <expression>2Request[Eval[environment]] customer].
let<identifier> = <expression>valuein<expression>body
When message[Eval[environment] customer] is received, then create a new evalCustomer and send <expression>value
Request[Eval[environment] evalCustomer1.
When evalCustomer receives Returned[theValue], create a new bindingCustomer and send environment
Request[bind[<identifier> theValue] bindingCustomer]
When bindingCustomer receives Returned[environment’], send <expression>bodyRequest[Eval[environment’] customer]
serializer<expression>
When Request[Eval[environment] customer] is received, then send customerReturned[theSerializer] where theSerializer is a new actor such that communications sent to theSerializer are processed in FIFO order with a behavior Actor that is initially <expression>.Eval[environment] and
When communication com is received by theSerializer, then send the behavior Actor Request[com customer’] where customer’ is a new actor such that
when customer’ receives Returned[theNextBehavior] then theNextBehavior is used as the behavior Actor for the next communication received by theSerializer.

Example program

An example program for a simple storage cell that can contain any Actor address is as follows:

Cell ≡
receiver
Request[Create[initial] customer]
send customer Returned[serializer ReadWrite(initial)]

The above program which creates a storage cell makes use of the behavior ReadWrite which is defined as follows:

ReadWrite(contents) ≡
behavior
Request[read[] customer]
{send customer Returned[contents], ReadWrite(contents)}
Request[write[x] customer]
{send customer Returned[], ReadWrite(x)}

Note that the above behavior is pipelined, i.e., the behavior might still be processing a previous read or write message while it is processing a subsequent read or write message.. For example, the following expression creates a cell x with initial contents 5 and then concurrently writes to it with the values 7 and 9.

let x = Cell.Create[5] in {x.write[7], x.write[9], x.read[]}

The value of the above expression is 5, 7 or 9.

See also

Related Research Articles

Message Passing Interface (MPI) is a standardized and portable message-passing standard designed to function on parallel computing architectures. The MPI standard defines the syntax and semantics of library routines that are useful to a wide range of users writing portable message-passing programs in C, C++, and Fortran. There are several open-source MPI implementations, which fostered the development of a parallel software industry, and encouraged development of portable and scalable large-scale parallel applications.

Email marketing is the act of sending a commercial message, typically to a group of people, using email. In its broadest sense, every email sent to a potential or current customer could be considered email marketing. It involves using email to send advertisements, request business, or solicit sales or donations. Email marketing strategies commonly seek to achieve one or more of three primary objectives, to building loyalty, trust, or brand awareness. The term usually refers to sending email messages with the purpose of enhancing a merchant's relationship with current or previous customers, encouraging customer loyalty and repeat business, acquiring new customers or convincing current customers to purchase something immediately, and sharing third-party ads.

In computer science, message passing is a technique for invoking behavior on a computer. The invoking program sends a message to a process and relies on that process and its supporting infrastructure to then select and run some appropriate code. Message passing differs from conventional programming where a process, subroutine, or function is directly invoked by name. Message passing is key to some models of concurrency and object-oriented programming.

The actor model in computer science is a mathematical model of concurrent computation that treats an actor as the basic building block of concurrent computation. In response to a message it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify their own private state, but can only affect each other indirectly through messaging.

D-Bus is a message-oriented middleware mechanism that allows communication between multiple processes running concurrently on the same machine. D-Bus was developed as part of the freedesktop.org project, initiated by GNOME developer Havoc Pennington to standardize services provided by Linux desktop environments such as GNOME and KDE.

In theoretical computer science, Actor model theory concerns theoretical issues for the Actor model.

In computer science, the Actor model and process calculi are two closely related approaches to the modelling of concurrent digital computation. See Actor model and process calculi history.

In computer science, future, promise, delay, and deferred refer to constructs used for synchronizing program execution in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is not yet complete.

In computer science, the Actor model, first published in 1973, is a mathematical model of concurrent computation.

In computer science, unbounded nondeterminism or unbounded indeterminacy is a property of concurrency by which the amount of delay in servicing a request can become unbounded as a result of arbitration of contention for shared resources while still guaranteeing that the request will eventually be serviced. Unbounded nondeterminism became an important issue in the development of the denotational semantics of concurrency, and later became part of research into the theoretical concept of hypercomputation.

In denotational semantics and domain theory, power domains are domains of nondeterministic and concurrent computations.

Indeterminacy in concurrent computation is concerned with the effects of indeterminacy in concurrent computation. Computation is an area in which indeterminacy is becoming increasingly important because of the massive increase in concurrency due to networking and the advent of many-core computer architectures. These computer systems make use of arbiters which gives rise to indeterminacy.

The actor model and process calculi share an interesting history and co-evolution.

The denotational semantics of the Actor model is the subject of denotational domain theory for Actors. The historical development of this subject is recounted in [Hewitt 2008b].

In computer science, the Actor model, first published in 1973, is a mathematical model of concurrent computation. This article reports on the middle history of the Actor model in which major themes were initial implementations, initial applications, and development of the first proof theory and denotational model. It is the follow on article to Actor model early history which reports on the early history of the Actor model which concerned the basic development of the concepts. The article Actor model later history reports on developments after the ones reported in this article.

In computer science, the Actor model, first published in 1973, is a mathematical model of concurrent computation. This article reports on the later history of the Actor model in which major themes were investigation of the basic power of the model, study of issues of compositionality, development of architectures, and application to Open systems. It is the follow on article to Actor model middle history which reports on the initial implementations, initial applications, and development of the first proof theory and denotational model.

Gul Agha is a professor of computer science at the University of Illinois at Urbana-Champaign, and director of the Open Systems Laboratory. He is known for his work on the actor model of concurrent computation, and was also Editor-in-Chief of ACM Computing Surveys from 1999 to 2007. Agha was born and completed his early schooling in Sindh, Pakistan. Agha completed his B.S. with honors at the California Institute of Technology in the year 1977. He received his Ph.D. in Computer and Communication Science from the University of Michigan in 1986 under the supervision of John Holland. However, much of his doctoral research was carried out in Carl Hewitt's Message-Passing Semantics Group at Massachusetts Institute of Technology (MIT). Agha's dissertation was published by the MIT Press as Actors: a model of concurrent computation in distributed systems, a book which, according to the ACM Guide to Computing Literature, has been cited over 3000 times.

<span class="mw-page-title-main">Carl Hewitt</span> American computer scientist; Planner programming languagedesigner (1944-2022)

Carl Eddie Hewitt was an American computer scientist who designed the Planner programming language for automated planning and the actor model of concurrent computation, which have been influential in the development of logic, functional and object-oriented programming. Planner was the first programming language based on procedural plans invoked using pattern-directed invocation from assertions and goals. The actor model influenced the development of the Scheme programming language, the π-calculus, and served as an inspiration for several other programming languages.

The history of the programming language Scheme begins with the development of earlier members of the Lisp family of languages during the second half of the twentieth century. During the design and development period of Scheme, language designers Guy L. Steele and Gerald Jay Sussman released an influential series of Massachusetts Institute of Technology (MIT) AI Memos known as the Lambda Papers (1975–1980). This resulted in the growth of popularity in the language and the era of standardization from 1990 onward. Much of the history of Scheme has been documented by the developers themselves.

Join-patterns provides a way to write concurrent, parallel and distributed computer programs by message passing. Compared to the use of threads and locks, this is a high level programming model using communication constructs model to abstract the complexity of concurrent environment and to allow scalability. Its focus is on the execution of a chord between messages atomically consumed from a group of channels.

References