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 (removing the need for lock-based synchronization).
The actor model originated in 1973. [1] It has been used both as a framework for a theoretical understanding of computation and as the theoretical basis for several practical implementations of concurrent systems. The relationship of the model to other work is discussed in actor model and process calculi.
According to Carl Hewitt, unlike previous models of computation, the actor model was inspired by physics, including general relativity and quantum mechanics.[ citation needed ] It was also influenced by the programming languages Lisp, Simula, early versions of Smalltalk, capability-based systems, and packet switching. Its development was "motivated by the prospect of highly parallel computing machines consisting of dozens, hundreds, or even thousands of independent microprocessors, each with its own local memory and communications processor, communicating via a high-performance communications network." [2] Since that time, the advent of massive concurrency through multi-core and manycore computer architectures has revived interest in the actor model.
Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the actor model as part of her doctoral research. [3] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for actor systems. [4] [5] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains [2] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's. [6] This resulted in the full development of actor model theory.
Major software implementation work was done by Russ Atkinson, Giuseppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman, Carl Manning, Tom Reinhardt, Richard Steiger and Dan Theriault in the Message Passing Semantics Group at Massachusetts Institute of Technology (MIT). Research groups led by Chuck Seitz at California Institute of Technology (Caltech) and Bill Dally at MIT constructed computer architectures that further developed the message passing in the model. See Actor model implementation.
Research on the actor model has been carried out at California Institute of Technology, Kyoto University Tokoro Laboratory, Microelectronics and Computer Technology Corporation (MCC), MIT Artificial Intelligence Laboratory, SRI, Stanford University, University of Illinois at Urbana–Champaign, [7] Pierre and Marie Curie University (University of Paris 6), University of Pisa, University of Tokyo Yonezawa Laboratory, Centrum Wiskunde & Informatica (CWI) and elsewhere.
The actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages.
An actor is a computational entity that, in response to a message it receives, can concurrently:
There is no assumed sequence to the above actions and they could be carried out in parallel.
Decoupling the sender from communications sent was a fundamental advance of the actor model enabling asynchronous communication and control structures as patterns of passing messages. [8]
Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created.
The actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronous message passing with no restriction on message arrival order.
Over the years, several different formal systems have been developed which permit reasoning about systems in the actor model. These include:
There are also formalisms that are not fully faithful to the actor model in that they do not formalize the guaranteed delivery of messages including the following (See Attempts to relate actor semantics to algebra and linear logic):
The actor model can be used as a framework for modeling, understanding, and reasoning about a wide range of concurrent systems. [15] For example:
The actor model is about the semantics of message passing.
Arguably, the first concurrent programs were interrupt handlers. During the course of its normal operation a computer needed to be able to receive information from outside (characters from a keyboard, packets from a network, etc). So when the information arrived the execution of the computer was interrupted and special code (called an interrupt handler) was called to put the information in a data buffer where it could be subsequently retrieved.
In the early 1960s, interrupts began to be used to simulate the concurrent execution of several programs on one processor. [17] Having concurrency with shared memory gave rise to the problem of concurrency control. Originally, this problem was conceived as being one of mutual exclusion on a single computer. Edsger Dijkstra developed semaphores and later, between 1971 and 1973, [18] Tony Hoare [19] and Per Brinch Hansen [20] developed monitors to solve the mutual exclusion problem. However, neither of these solutions provided a programming language construct that encapsulated access to shared resources. This encapsulation was later accomplished by the serializer construct ([Hewitt and Atkinson 1977, 1979] and [Atkinson 1980]).
The first models of computation (e.g., Turing machines, Post productions, the lambda calculus, etc.) were based on mathematics and made use of a global state to represent a computational step (later generalized in [McCarthy and Hayes 1969] and [Dijkstra 1976] see Event orderings versus global state). Each computational step was from one global state of the computation to the next global state. The global state approach was continued in automata theory for finite-state machines and push down stack machines, including their nondeterministic versions. Such nondeterministic automata have the property of bounded nondeterminism; that is, if a machine always halts when started in its initial state, then there is a bound on the number of states in which it halts.
Edsger Dijkstra further developed the nondeterministic global state approach. Dijkstra's model gave rise to a controversy concerning unbounded nondeterminism (also called unbounded indeterminacy), 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. Hewitt argued that the actor model should provide the guarantee of service. In Dijkstra's model, although there could be an unbounded amount of time between the execution of sequential instructions on a computer, a (parallel) program that started out in a well defined state could terminate in only a bounded number of states [Dijkstra 1976]. Consequently, his model could not provide the guarantee of service. Dijkstra argued that it was impossible to implement unbounded nondeterminism.
Hewitt argued otherwise: there is no bound that can be placed on how long it takes a computational circuit called an arbiter to settle (see metastability (electronics)). [21] Arbiters are used in computers to deal with the circumstance that computer clocks operate asynchronously with respect to input from outside, e.g., keyboard input, disk access, network input, etc. So it could take an unbounded time for a message sent to a computer to be received and in the meantime the computer could traverse an unbounded number of states.
The actor model features unbounded nondeterminism which was captured in a mathematical model by Will Clinger using domain theory. [2] In the actor model, there is no global state.[ dubious – discuss ]
Messages in the actor model are not necessarily buffered. This was a sharp break with previous approaches to models of concurrent computation. The lack of buffering caused a great deal of misunderstanding at the time of the development of the actor model and is still a controversial issue. Some researchers argued that the messages are buffered in the "ether" or the "environment". Also, messages in the actor model are simply sent (like packets in IP); there is no requirement for a synchronous handshake with the recipient.
A natural development of the actor model was to allow addresses in messages. Influenced by packet switched networks [1961 and 1964], Hewitt proposed the development of a new model of concurrent computation in which communications would not have any required fields at all: they could be empty. Of course, if the sender of a communication desired a recipient to have access to addresses which the recipient did not already have, the address would have to be sent in the communication.
For example, an actor might need to send a message to a recipient actor from which it later expects to receive a response, but the response will actually be handled by a third actor component that has been configured to receive and handle the response (for example, a different actor implementing the observer pattern). The original actor could accomplish this by sending a communication that includes the message it wishes to send, along with the address of the third actor that will handle the response. This third actor that will handle the response is called the resumption (sometimes also called a continuation or stack frame). When the recipient actor is ready to send a response, it sends the response message to the resumption actor address that was included in the original communication.
So, the ability of actors to create new actors with which they can exchange communications, along with the ability to include the addresses of other actors in messages, gives actors the ability to create and participate in arbitrarily variable topological relationships with one another, much as the objects in Simula and other object-oriented languages may also be relationally composed into variable topologies of message-exchanging objects.
As opposed to the previous approach based on composing sequential processes, the actor model was developed as an inherently concurrent model. In the actor model sequentiality was a special case that derived from concurrent computation as explained in actor model theory.
This section needs additional citations for verification .(March 2012) |
Hewitt argued against adding the requirement that messages must arrive in the order in which they are sent to the actor. If output message ordering is desired, then it can be modeled by a queue actor that provides this functionality. Such a queue actor would queue the messages that arrived so that they could be retrieved in FIFO order. So if an actor X
sent a message M1
to an actor Y
, and later X
sent another message M2
to Y
, there is no requirement that M1
arrives at Y
before M2
.
In this respect the actor model mirrors packet switching systems which do not guarantee that packets must be received in the order sent. Not providing the order of delivery guarantee allows packet switching to buffer packets, use multiple paths to send packets, resend damaged packets, and to provide other optimizations.
For more example, actors are allowed to pipeline the processing of messages. What this means is that in the course of processing a message M1
, an actor can designate the behavior to be used to process the next message, and then in fact begin processing another message M2
before it has finished processing M1
. Just because an actor is allowed to pipeline the processing of messages does not mean that it must pipeline the processing. Whether a message is pipelined is an engineering tradeoff. How would an external observer know whether the processing of a message by an actor has been pipelined? There is no ambiguity in the definition of an actor created by the possibility of pipelining. Of course, it is possible to perform the pipeline optimization incorrectly in some implementations, in which case unexpected behavior may occur.
Another important characteristic of the actor model is locality.
Locality means that in processing a message, an actor can send messages only to addresses that it receives in the message, addresses that it already had before it received the message, and addresses for actors that it creates while processing the message. (But see Synthesizing addresses of actors.)
Also locality means that there is no simultaneous change in multiple locations. In this way it differs from some other models of concurrency, e.g., the Petri net model in which tokens are simultaneously removed from multiple locations and placed in other locations.
The idea of composing actor systems into larger ones is an important aspect of modularity that was developed in Gul Agha's doctoral dissertation, [6] developed later by Gul Agha, Ian Mason, Scott Smith, and Carolyn Talcott. [9]
A key innovation was the introduction of behavior specified as a mathematical function to express what an actor does when it processes a message, including specifying a new behavior to process the next message that arrives. Behaviors provided a mechanism to mathematically model the sharing in concurrency.
Behaviors also freed the actor model from implementation details, e.g., the Smalltalk-72 token stream interpreter. However, the efficient implementation of systems described by the actor model require extensive optimization. See Actor model implementation for details.
Other concurrency systems (e.g., process calculi) can be modeled in the actor model using a two-phase commit protocol. [22]
There is a Computational Representation Theorem in the actor model for systems which are closed in the sense that they do not receive communications from outside. The mathematical denotation denoted by a closed system is constructed from an initial behavior and a behavior-approximating function These obtain increasingly better approximations and construct a denotation (meaning) for as follows [Hewitt 2008; Clinger 1981]:
In this way, can be mathematically characterized in terms of all its possible behaviors (including those involving unbounded nondeterminism). Although is not an implementation of , it can be used to prove a generalization of the Church-Turing-Rosser-Kleene thesis [Kleene 1943]:
A consequence of the above theorem is that a finite actor can nondeterministically respond with an uncountable[ clarify ] number of different outputs.
This section needs additional citations for verification .(March 2012) |
One of the key motivations for the development of the actor model was to understand and deal with the control structure issues that arose in development of the Planner programming language.[ citation needed ] Once the actor model was initially defined, an important challenge was to understand the power of the model relative to Robert Kowalski's thesis that "computation can be subsumed by deduction". Hewitt argued that Kowalski's thesis turned out to be false for the concurrent computation in the actor model (see Indeterminacy in concurrent computation).
Nevertheless, attempts were made to extend logic programming to concurrent computation. However, Hewitt and Agha [1991] claimed that the resulting systems were not deductive in the following sense: computational steps of the concurrent logic programming systems do not follow deductively from previous steps (see Indeterminacy in concurrent computation). Recently, logic programming has been integrated into the actor model in a way that maintains logical semantics. [21]
Migration in the actor model is the ability of actors to change locations. E.g., in his dissertation, Aki Yonezawa modeled a post office that customer actors could enter, change locations within while operating, and exit. An actor that can migrate can be modeled by having a location actor that changes when the actor migrates. However the faithfulness of this modeling is controversial and the subject of research.[ citation needed ]
This section needs additional citations for verification .(August 2021) |
The security of actors can be protected in the following ways:
This section needs additional citations for verification .(March 2012) |
A delicate point in the actor model is the ability to synthesize the address of an actor. In some cases security can be used to prevent the synthesis of addresses (see Security). However, if an actor address is simply a bit string then clearly it can be synthesized although it may be difficult or even infeasible to guess the address of an actor if the bit strings are long enough. SOAP uses a URL for the address of an endpoint where an actor can be reached. Since a URL is a character string, it can clearly be synthesized although encryption can make it virtually impossible to guess.
Synthesizing the addresses of actors is usually modeled using mapping. The idea is to use an actor system to perform the mapping to the actual actor addresses. For example, on a computer the memory structure of the computer can be modeled as an actor system that does the mapping. In the case of SOAP addresses, it's modeling the DNS and the rest of the URL mapping.
Robin Milner's initial published work on concurrency [23] was also notable in that it was not based on composing sequential processes. His work differed from the actor model because it was based on a fixed number of processes of fixed topology communicating numbers and strings using synchronous communication. The original communicating sequential processes (CSP) model [24] published by Tony Hoare differed from the actor model because it was based on the parallel composition of a fixed number of sequential processes connected in a fixed topology, and communicating using synchronous message-passing based on process names (see Actor model and process calculi history). Later versions of CSP abandoned communication based on process names in favor of anonymous communication via channels, an approach also used in Milner's work on the calculus of communicating systems (CCS) and the π-calculus.
These early models by Milner and Hoare both had the property of bounded nondeterminism. Modern, theoretical CSP ([Hoare 1985] and [Roscoe 2005]) explicitly provides unbounded nondeterminism.
Petri nets and their extensions (e.g., coloured Petri nets) are like actors in that they are based on asynchronous message passing and unbounded nondeterminism, while they are like early CSP in that they define fixed topologies of elementary processing steps (transitions) and message repositories (places).
The actor model has been influential on both theory development and practical software development.
The actor model has influenced the development of the π-calculus and subsequent process calculi. In his Turing lecture, Robin Milner wrote: [25]
Now, the pure lambda-calculus is built with just two kinds of thing: terms and variables. Can we achieve the same economy for a process calculus? Carl Hewitt, with his actors model, responded to this challenge long ago; he declared that a value, an operator on values, and a process should all be the same kind of thing: an actor.
This goal impressed me, because it implies the homogeneity and completeness of expression ... But it was long before I could see how to attain the goal in terms of an algebraic calculus...
So, in the spirit of Hewitt, our first step is to demand that all things denoted by terms or accessed by names—values, registers, operators, processes, objects—are all of the same kind of thing; they should all be processes.
The actor model has had extensive influence on commercial practice. For example, Twitter has used actors for scalability. [26] Also, Microsoft has used the actor model in the development of its Asynchronous Agents Library. [27] There are many other actor libraries listed in the actor libraries and frameworks section below.
According to Hewitt [2006], the actor model addresses issues in computer and communications architecture, concurrent programming languages, and Web services including the following:
Many of the ideas introduced in the actor model are now also finding application in multi-agent systems for these same reasons [Hewitt 2006b 2007b]. The key difference is that agent systems (in most definitions) impose extra constraints upon the actors, typically requiring that they make use of commitments and goals.
A number of different programming languages employ the actor model or some variation of it. These languages include:
Actor libraries or frameworks have also been implemented to permit actor-style programming in languages that don't have actors built-in. Some of these frameworks are:
Name | Status | Latest release | License | Languages |
---|---|---|---|---|
Otavia | Active | 2024-01-02 | Apache 2.0 | Scala |
Abstractor | Active | 2024-03-04 | Apache 2.0 | Java |
Xcraft Goblins | Active | 2022-08-30 | MIT | JavaScript |
ReActed | Active | 2022-11-30 | Apache 2.0 | Java |
Acteur | Active | 2020-04-16 [47] | Apache-2.0 / MIT | Rust |
Bastion | Active | 2020-08-12 [48] | Apache-2.0 / MIT | Rust |
Actix | Active | 2020-09-11 [49] | MIT | Rust |
Aojet | Active | 2016-10-17 | MIT | Swift |
Actor | Active | 2017-03-09 | MIT | Java |
Actor4j | Active | 2020-01-31 | Apache 2.0 | Java |
Actr | Active | 2019-04-09 [50] | Apache 2.0 | Java |
Vert.x | Active | 2018-02-13 | Apache 2.0 | Java, Groovy, Javascript, Ruby, Scala, Kotlin, Ceylon |
ActorFx | Inactive | 2013-11-13 | Apache 2.0 | .NET |
Akka (toolkit) | Active | 2022-09-06 [51] | Commercial [52] (from 2.7.0, Apache 2.0 up to 2.6.20) | Java and Scala |
Akka.NET | Active | 2020-08-20 [53] | Apache 2.0 | .NET |
Apache Pekko | Active | 2023-07-26 [54] | Apache 2.0 | Java and Scala |
Dapr | Active | 2019-10-16 | Apache 2.0 | Java, .NET Core, Go, Javascript, Python, Rust and C++ |
DOTNETACTORS | Active | 2021-06-14 | MIT | .NET, C#, Azure Service Bus |
Remact.Net | Inactive | 2016-06-26 | MIT | .NET, Javascript |
Ateji PX | Inactive | ? | ? | Java |
czmq | Active | 2016-11-10 | MPL-2 | C |
F# MailboxProcessor | Active | same as F# (built-in core library) | Apache License | F# |
Korus | Active | 2010-02-04 | GPL 3 | Java |
Kilim [55] | Active | 2018-11-09 [56] | MIT | Java |
ActorFoundry (based on Kilim) | Inactive | 2008-12-28 | ? | Java |
ActorKit | Active | 2011-09-13 [57] | BSD | Objective-C |
Cloud Haskell | Active | 2024-04-30 [58] | BSD | Haskell |
CloudI | Active | 2023-10-27 [59] | MIT | ATS, C/C++, Elixir/Erlang/LFE, Go, Haskell, Java, Javascript, OCaml, Perl, PHP, Python, Ruby, Rust |
Clutter | Active | 2017-05-12 [60] | LGPL 2.1 | C, C++ (cluttermm), Python (pyclutter), Perl (perl-Clutter) |
NAct | Inactive | 2012-02-28 | LGPL 3.0 | .NET |
Nact Archived 2021-02-05 at the Wayback Machine | Active | 2018-06-06 [61] | Apache 2.0 | JavaScript/ReasonML |
Retlang | Inactive | 2011-05-18 [62] | New BSD | .NET |
JActor | Inactive | 2013-01-22 | LGPL | Java |
Jetlang | Active | 2013-05-30 [63] | New BSD | Java |
Haskell-Actor | Active? | 2008 | New BSD | Haskell |
GPars | Active | 2014-05-09 [64] | Apache 2.0 | Groovy |
OOSMOS | Active | 2019-05-09 [65] | GPL 2.0 and commercial (dual licensing) | C. C++ friendly |
Panini | Active | 2014-05-22 | MPL 1.1 | Programming Language by itself |
PARLEY | Active? | 2007-22-07 | GPL 2.1 | Python |
Peernetic | Active | 2007-06-29 | LGPL 3.0 | Java |
Picos | Active | 2020-02-04 | MIT | KRL |
PostSharp | Active | 2014-09-24 | Commercial / Freemium | .NET |
Pulsar | Active | 2016-07-09 [66] | New BSD | Python |
Pulsar | Active | 2016-02-18 [67] | LGPL/Eclipse | Clojure |
Pykka | Active | 2019-05-07 [68] | Apache 2.0 | Python |
Termite Scheme | Active? | 2009-05-21 | LGPL | Scheme (Gambit implementation) |
Theron | Inactive [69] | 2014-01-18 [70] | MIT [71] | C++ |
Thespian | Active | 2020-03-10 | MIT | Python |
Quasar | Active | 2018-11-02 [72] | LGPL/Eclipse | Java |
Libactor | Active? | 2009 | GPL 2.0 | C |
Actor-CPP | Active | 2012-03-10 [73] | GPL 2.0 | C++ |
S4 | Inactive | 2012-07-31 [74] | Apache 2.0 | Java |
C++ Actor Framework (CAF) | Active | 2020-02-08 [75] | Boost Software License 1.0 and BSD 3-Clause | C++11 |
Celluloid | Active | 2018-12-20 [76] | MIT | Ruby |
LabVIEW Actor Framework | Active | 2012-03-01 [77] | National Instruments SLA | LabVIEW |
LabVIEW Messenger Library | Active | 2021-05-24 | BSD | LabVIEW |
Orbit | Active | 2019-05-28 [78] | New BSD | Java |
QP frameworks for real-time embedded systems | Active | 2019-05-25 [79] | GPL 2.0 and commercial (dual licensing) | C and C++ |
libprocess | Active | 2013-06-19 | Apache 2.0 | C++ |
SObjectizer | Active | 2024-11-02 [80] | New BSD | C++17 |
rotor | Active | 2022-04-23 [81] | MIT License | C++17 |
Orleans | Active | 2023-07-11 [82] | MIT License | C#/.NET |
Skynet | Active | 2020-12-10 | MIT License | C/Lua |
Reactors.IO | Active | 2016-06-14 | BSD License | Java/Scala |
libagents | Active | 2020-03-08 | Free software license | C++11 |
Proto.Actor | Active | 2021-01-05 | Free software license | Go, C#, Python, JavaScript, Kotlin |
FunctionalJava Archived 2021-04-22 at the Wayback Machine | Active | 2018-08-18 [83] | BSD 3-Clause | Java |
Riker | Active | 2019-01-04 | MIT License | Rust |
Comedy | Active | 2019-03-09 | EPL 1.0 | JavaScript |
VLINGO XOOM Actors | Active | 2023-02-15 | Mozilla Public License 2.0 | Java, Kotlin, JVM languages, C# .NET |
wasmCloud | Active | 2021-03-23 | Apache 2.0 | WebAssembly (Rust, TinyGo, Zig, AssemblyScript) |
ray | Active | 2020-08-27 | Apache 2.0 | Python |
cell | Active | 2012-08-02 | New BSD License | Python |
go-actor | Active | 2022-08-16 | MIT License | Go |
Sento | Active | 2022-11-21 | Apache 2.0 | Common Lisp |
Tarant | Active | 2023-04-17 | MIT | Typescript, Javascript |
In computer science, denotational semantics is an approach of formalizing the meanings of programming languages by constructing mathematical objects that describe the meanings of expressions from the languages. Other approaches providing formal semantics of programming languages include axiomatic semantics and operational semantics.
Programming languages can be grouped by the number and types of paradigms supported.
In computer science, concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the outcome. This allows for parallel execution of the concurrent units, which can significantly improve overall speed of the execution in multi-processor and multi-core systems. In more technical terms, concurrency refers to the decomposability of a program, algorithm, or problem into order-independent or partially-ordered components or units of computation.
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.
In theoretical computer science, Actor model theory concerns theoretical issues for the Actor model.
In computer science, Actor model implementation concerns implementation 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 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.
Akinori Yonezawa(born June 17, 1947) is a Japanese computer scientist. Professor Emeritus of the University of Tokyo. Received Ph.D. from the Massachusetts Institute of Technology (MIT). Currently, a senior fellow at the Chiba Institute of Technology, Software Technology and Artificial Intelligence Research Center. Former member of the Science Council of Japan. Specializes in object-oriented programming languages, distributed computing and information security. From its beginning, he contributed to the promotion and development of object-oriented programming, which is the basis of programming languages most commonly used today, and served as a program committee member and chairman of the main international conferences OOPSLA and ECOOP. At the same time, he is internationally known as a pioneer of the concepts and models of “concurrent/parallel objects". In software systems constructed based on concurrent/parallel objects, information processing and computation proceed by concurrent/parallel message passing among a large number of objects. Yonezawa's concurrent (parallel) objects are influenced by Actors, the concept of which was proposed by Carl Hewitt at MIT's AI Lab in the early 1970s and later rigorously formulated by Gul Agha. However, concurrent objects and actors are fundamentally different. An actor is an object that does not have a "state," whereas Yonezawa's concurrent (parallel) object can have a persistent state. For this reason, concurrent (parallel) objects are often used in implementing large parallel processing software systems. Large-scale software systems built and put into practical use based on concurrent (parallel) objects include an online virtual world system Second Life, social networking services such as Facebook and X (Twitter), and large-scale molecular dynamics simulation systems such as NAMD.
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.
{{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help)