imported>Zyploc: The term 'actor' is not a proper noun and is not capitalized in the body of corresponding pages, e.g. Actor model.

2025-06-09T07:46:59Z

The term 'actor' is not a proper noun and is not capitalized in the body of corresponding pages, e.g. Actor model.

New page

{{Short description|In computer science}}
{{No footnotes|date=August 2023}}
{{Copied to Wikibooks}}

In [[computer science]], '''actor model implementation''' concerns implementation issues for the [[actor model]].

==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 switch|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:
*Asynchronous messaging
*A uniform space of actor addresses to which messages could be sent concurrently regardless of whether the recipient actor was local or nonlocal
*A form of actor pipelining (see [[actor model]])
Concurrent Smalltalk (which can be modeled using [[actor model|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
<kbd>:<tag>[<element>1 ... <element>] for</kbd>
:<kbd>“<”<tag>“>” <element>1 ... <element>n “<”/<tag>“>”</kbd>

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 <kbd>Eval</kbd> 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 <kbd>Request[Bind[identifier value] customer]</kbd> is received by an actor environment, a new environment actor is created such that
when the new environment actor receives
<kbd>Request[Lookup[identifier’] customer’]</kbd> then if <kbd>identifier</kbd> is the same as <kbd>identifier’</kbd> send <kbd>customer’</kbd> <kbd>Returned[value]</kbd>, else send <kbd>Environment
Request[Lookup[identifier’] customer’]</kbd>.
The above builds on an actor <kbd>EmptyEnvironment</kbd> which
when it receives <kbd>Request[Lookup[identifier] customer]</kbd>, sends <kbd>customer</kbd> <kbd>Thrown[NotFound[identifier]]</kbd>.
When it receives a <kbd>Bind</kbd> request <kbd>EmptyEnvironment</kbd> acts like <kbd>Environment</kbd> above.

===Expressions===
The prototype programming language has expressions of the following kinds:

; <identifier>
:When <kbd>Request[Eval[environment] customer]</kbd> is received, send <kbd>environment</kbd> <kbd>Request[Lookup[<identifier>] customer]</kbd>

; ''send'' <recipient> <communication>
:When <kbd>Request[Eval[environment] customer]</kbd> is received, send <kbd><recipient></kbd> <kbd>Request[Eval[environment] evalCustomer1]</kbd> where <kbd>evalCustomer1</kbd> is a new actor such that
:when <kbd>evalCustomer1</kbd> receives the communication <kbd>Returned[theRecipient]</kbd>, then send <kbd><communication></kbd>
:<kbd>Request[Eval[environment] evalCustomer2]</kbd> where <kbd>evalCustomer2</kbd> is a new actor such that
:when <kbd>evalCustomer2</kbd> receives the communication <kbd>Returned[theCommunication]</kbd>, then send <kbd>theRecipient</kbd> <kbd>theCommunication</kbd>.

;<recipient>.<message>
:When <kbd>Request[Eval[environment] customer]</kbd> is received, send <kbd><recipient></kbd> <kbd>Request[Eval[environment] evalCustomer1]</kbd> such that
:when <kbd>evalCustomer1</kbd> receives the communication <kbd>Returned[theRecipient]</kbd>, then send <kbd><message></kbd> <kbd>Request[Eval[environment] evalCustomer2]</kbd> such that
:when <kbd>evalCustomer2</kbd> receives the communication <kbd>Returned[theMessage]</kbd>, then send <kbd>theRecipient</kbd>
:<kbd>Request[theMessage customer]</kbd>

;''receiver'' ... <pattern>i <expression>i ...
:When <kbd>Request[Eval[environment] customer]</kbd> is received, send <kbd>customer</kbd> a new actor <kbd>theReceiver</kbd> such that
:when <kbd>theReceiver</kbd> receives a communication <kbd>com</kbd>, then create a new <kbd>bindingCustomer</kbd> and send environment
:<kbd>Request[Bind[<pattern>i com] bindingCustomer]</kbd> and
:if <kbd>bindingCustomer</kbd> receives <kbd>Returned[environment’]</kbd>, send <kbd><expression>i</kbd>
:<kbd>Request[Eval[environment’]]</kbd>
:otherwise if <kbd>bindingCustomer</kbd> receives <kbd>Thrown[...]</kbd>, try <kbd><pattern>i+1</kbd>

; ''behavior'' ... <pattern>i <expression>i ...
:When <kbd>Request[Eval[environment] customer]</kbd> is received, send customer a new actor <kbd>theReceiver</kbd> such that
:when <kbd>theReceiver</kbd> receives <kbd>Request[message customer’]</kbd>, then create a new <kbd>bindingCustomer</kbd> and send <kbd>environment</kbd>
:<kbd>Request[bind[<pattern>i message] customer’]</kbd> and
:# if <kbd>bindingCustomer</kbd> receives <kbd>Returned[environment’]</kbd>, send <kbd><expression>i</kbd>
:#:<kbd>Request[Eval[environment’] customer’]</kbd>
:# otherwise if <kbd>bindingCustomer</kbd> receives <kbd>Thrown[...]</kbd>, try <kbd><pattern>i+1</kbd>

;{<expression>1, <expression>2}
:When <kbd>Request[Eval[environment] customer]</kbd> is received, send <kbd><expression>1</kbd> <kbd>Request[Eval[environment]]</kbd> and concurrently send <kbd><expression>2</kbd> <kbd>Request[Eval[environment]] customer]</kbd>.

; ''let'' <identifier> = <expression>value ''in'' <expression>body
:When <kbd>message[Eval[environment] customer]</kbd> is received, then create a new <kbd>evalCustomer</kbd> and send <kbd><expression>value</kbd>
:<kbd>Request[Eval[environment] evalCustomer1</kbd>.
:When <kbd>evalCustomer</kbd> receives <kbd>Returned[theValue]</kbd>, create a new <kbd>bindingCustomer</kbd> and send <kbd>environment</kbd>
:<kbd>Request[bind[<identifier> theValue] bindingCustomer]</kbd>
:When <kbd>bindingCustomer</kbd> receives <kbd>Returned[environment’]</kbd>, send <kbd><expression>body</kbd> <kbd>Request[Eval[environment’] customer]</kbd>

; ''serializer'' <expression>
:When <kbd>Request[Eval[environment] customer]</kbd> is received, then send <kbd>customer</kbd> <kbd>Returned[theSerializer]</kbd> where <kbd>theSerializer</kbd> is a new actor such that communications sent to <kbd>theSerializer</kbd> are processed in FIFO order with a behavior actor that is initially <kbd><expression>.Eval[environment]</kbd> and
:When communication <kbd>com</kbd> is received by <kbd>theSerializer</kbd>, then send the behavior actor <kbd>Request[com customer’]</kbd> where <kbd>customer’</kbd> is a new actor such that
:when <kbd>customer’</kbd> receives <kbd>Returned[theNextBehavior]</kbd> then <kbd>theNextBehavior</kbd> is used as the behavior actor for the next communication received by <kbd>theSerializer</kbd>.

===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)}

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==
* [[actor model and process calculi]]
* [[actor model theory]]

==References==
*[[Henry Baker (computer scientist)|Henry Baker]] and Carl Hewitt '''The Incremental Garbage Collection of Processes''' Proceedings of the Symposium on Artificial Intelligence Programming Languages. SIGPLAN Notices 12, August 1977.
*Peter Bishop '''Very Large Address Space Modularly Extensible Computer Systems''' MIT EECS Doctoral Dissertation. June 1977.
*Henry Baker. '''Actor Systems for Real-Time Computation''' MIT EECS Doctoral Dissertation. January 1978.
*Carl Hewitt and Russ Atkinson. '''Specification and Proof Techniques for Serializers''' IEEE Journal on Software Engineering. January 1979.
*Ken Kahn. '''A Computational Theory of Animation''' MIT EECS Doctoral Dissertation. August 1979.
*Carl Hewitt, Beppe Attardi, and Henry Lieberman. '''Delegation in Message Passing''' Proceedings of First International Conference on Distributed Systems Huntsville, AL. October 1979.
*Bill Kornfeld and Carl Hewitt. '''The Scientific Community Metaphor''' IEEE Transactions on Systems, Man, and Cybernetics. January 1981.
*Henry Lieberman. '''Thinking About Lots of Things at Once without Getting Confused: Parallelism in Act 1''' MIT AI memo 626. May 1981.
*Henry Lieberman. '''A Preview of Act 1''' MIT AI memo 625. June 1981.
*Bill Kornfeld. '''Parallelism in Problem Solving''' MIT EECS Doctoral Dissertation. August 1981.
*Daniel Theriault. '''A Primer for the Act-1 Language''' MIT AI memo 672. April 1982.
*Henry Lieberman and Carl Hewitt. '''A real Time Garbage Collector Based on the Lifetimes of Objects''' CACM June 1983.
*Daniel Theriault. '''Issues in the Design and Implementation of Act 2''' MIT AI technical report 728. June 1983.
*Henry Lieberman. '''An Object-Oriented Simulator for the Apiary''' Conference of the American Association for Artificial Intelligence, Washington, D. C., August 1983.
*Carl Hewitt and Henry Lieberman. '''Design Issues in Parallel Architecture for Artificial Intelligence''' MIT AI memo 750. Nov. 1983.
*Charles Seitz. '''The Cosmic Cube''' CACM. Jan. 1985.
*Carl Manning. '''Traveler: the actor observatory''' ECOOP 1987. Also appears in Lecture Notes in Computer Science, vol. 276.
*Carl Manning,. '''Acore: The Design of a Core Actor Language and its Compile''' MastersThesis. MIT EECS. May 1987.
*William Athas and Charles Seitz '''Multicomputers: message-passing concurrent computers''' IEEE Computer August 1988.
*William Athas and Nanette Boden '''Cantor: An actor Programming System for Scientific Computing''' in Proceedings of the NSF Workshop on Object-Based Concurrent Programming. 1988. Special Issue of SIGPLAN Notices.
*Jean-Pierre Briot. '''From objects to actors: Study of a limited symbiosis in Smalltalk-80''' Rapport de Recherche 88-58, RXF-LITP, Paris, France, September 1988
*William Dally and Wills, D. '''Universal mechanisms for concurrency''' PARLE ‘89.
*W. Horwat, A. Chien, and W. Dally. '''Experience with CST: Programming and Implementation''' PLDI. 1989.
*[[Akinori Yonezawa]], Ed. '''ABCL: An Object-Oriented Concurrent System''' MIT Press. 1990.
*Carl Hewitt and Gul Agha. '''Guarded Horn clause languages: are they deductive and Logical?''' in Artificial Intelligence at MIT, Vol. 2. MIT Press 1991.
*Carl Hewitt and Jeff Inman. '''DAI Betwixt and Between: From "Intelligent Agents" to Open Systems Science''' IEEE Transactions on Systems, Man, and Cybernetics. Nov./Dec. 1991.
*William Dally, ''et al.'' '''The Message-Driven Processor: A Multicomputer Processing Node with Efficient Mechanisms''' IEEE Micro. April 1992.
*Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer. '''Simple Object Access Protocol (SOAP) 1.1''' W3C Note. May 2000.
*{{cite document | author = Edward A. Lee and Stephen Neuendorffer | title = Classes and Subclasses in Actor-Oriented Design | doi =  | type = Ph.D. Dissertation - extended abstract | publisher = Conference on Formal Methods and Models for Codesign (MEMOCODE) | date = June 2004 }}
*Carl Hewitt. '''[https://web.archive.org/web/20171210124010/https://vvvvw.aaai.org/Papers/Symposia/Spring/2006/SS-06-08/SS06-08-003.pdf The repeated demise of logic programming and why it will be reincarnated]''' What Went Wrong and Why: Lessons from AI Research and Applications. Technical Report SS-06-08. AAAI Press. March 2006.

[[Category:Actor model (computer science)]]

Actor model implementation - Revision history

imported>Zyploc: The term 'actor' is not a proper noun and is not capitalized in the body of corresponding pages, e.g. Actor model.