PublishedinArXivhttp://arxiv.org/abs/0907.3330
http://ActorScript.carlhewitt.info
December14,2009Page
1
of42
Actor
Script™
:Industrial strength integration of local and nonlocal concurrencyfor Client-cloud Computing
Carl Hewitt
http://carlhewitt.info
This paper is dedicated to Seymour Papert.
Actor
Script™ is a general purpose programming language for implemen
ting massive local and nonlocalconcurrency. It is differentiated from other concurrent languages by the following:
Identifiers (names) in the language are referentially transparent,
i.e
., in a given scope an identifieralways refers to the same thing.
Everything in the language is accomplished using message passing including the very definition of ActorScript itself.
Binary XML and JSON are fundamental, being used for structuring both data and messages.
Functional and Logic Programming are integrated into general concurrent programming.
Advanced features such as eventing, co-routines, futures, serializers, sponsors, etc. can be defined andimplemented without having to resort to low level implementation mechanisms such as threads, tasks,channels, queues, locks, cores,
etc
.
For ease of reading, programming can be displayed using a 2-dimensional textual typography (as isoften done in mathematics).
ActorScript attempts to achieve the highest level of performance, scalability, and expressiblity with aminimum of primitives.
Contents
December14,2009Page
2
of42
Actor Model
i
ActorScript is based on
a mathematical model of computation
that treats “
Actors
”
as the universal primitivesof concurrent digital computation [Hewitt, Bishop, andSteiger 1973; Hewitt 1977]. Actors been used both as aframework for a theoretical understanding of concurrency,and as the theoretical basis for several practicalimplementations of concurrent systems.Unlike previous models of computation, the Actor modelwas inspired by physical laws. It was also influenced bythe programming languages Lisp [McCarthy
et. al.
1962],Simula[Dahl and Nygaard 1967] and Smalltalk-72 [Kay1975], as well as ideas for Petri Nets [Petri 1962],capability-based systems [Dennis and van Horn 1966] andpacket switching [Baran 1964]. Its development was
“
motivated by the prospect of highly parallel computingmachines consisting of dozens, hundreds or even thousandsof independent microprocessors, each with its own localmemory and communications processor, communicatingvia a high-performance communications network
.”
[Clinger 1981] Since that time, the advent of massiveconcurrency through client-cloud computing and many-core computer architectures has rekindled interest in theActor model [Hewitt 2009b].
Fundamental concepts
An Actor is a computational entity that, in response to amessage it receives, can concurrently:
send a finite number of messages to other Actors;
create a finite number of new Actors;
designate the behavior to be used for the nextmessage it receives.There is no assumed sequence to the above actions andthey could be carried out concurrently.Decoupling the sender from communications sent was afundamental advance of the Actor model enablingasynchronous communication and control structures aspatterns of passing messages [Hewitt 1977].An Actor can only communicate with Actors to which it isconnected. It can directly obtain information only fromother Actors to which it is directly connected. Connectionscan be implemented in a variety of ways:
direct physical attachment
memory or disk addresses
network addresses
email addressesThe Actor model is characterized by inherent concurrencyof computation within and among Actors, dynamiccreation of Actors, inclusion of Actor addresses inmessages, and interaction only through directasynchronous message passing with no restriction onmessage arrival order.
Illustrations
The Actor model can be used as a framework formodeling, understanding, and reasoning about, a widerange of concurrent systems. For example:
Electronic mail (e-mail) can be modeled as anActor system. Accounts are modeled as Actorsand email addresses as Actor addresses.
Web Services can be modeled with SOAPendpoints modeled as Actor addresses.
Objects with locks (
e.g.
as in Java and C#) can bemodeled as
serializers
(see below), provided thattheir implementations are such that messages cancontinually arrive.
Direct communication and asynchrony
Messages in the Actor model are decoupled from thesender and are delivered by the system on a best effortsbasis. This was a sharp break with previous approaches tomodels of concurrent computation in which messagesending is tightly coupled with the sender and sending amessage synchronously transfers it someplace
, e.g
., to a
buffer or to the “
ether
” or “
environment
” where it
temporarily resides. The lack of synchronicity caused agreat deal of misunderstanding at the time of thedevelopment of the Actor model and is still a controversialissue.Because message passing is taken as fundamental in theActor model, there cannot be any inherent overhead,
e.g.,
any requirement for buffers, channels,
etc
... Prior to theActor model, concurrency was defined in low levelmachine terms of threads, locks, channels, queues, cores,
etc
. It certainly is the case that implementations of theActor model typically make use of these hardwarecapabilities. However, there is no reason that the modelcould not be implemented directly in hardware withoutexposing any hardware threads, locks, queues, channels,tasks,
etc.
Also, there is no necessary relationship betweenthe number of Actors and the number threads, locks, tasks,queues,
etc.
that might be in use. Implementations of theActor model are free to make use of threads, locks, tasks,queues, global assignment, coherent memory, transactionalmemory, cores,
etc
. in any way that is compatible with thelaws for Actors.As opposed to the previous approach based on composingsequential processes, the Actor model was developed as aninherently concurrent model. In the Actor model sequential
December14,2009Page
3
of42
ordering is a special case that derived from concurrentcomputation.A natural development of the Actor model was to allowActor addresses in messages. A computation might need tosend a message to a recipient from which it would laterreceive a response. The way to do this is to send acommunication which has the message along with theaddress of another Actor called the
customer
along withthe message. The recipient could then cause a responsemessage to be sent to the customer.Of course, any Actor could be used as a customer toreceive a response message. By using customers, commoncontrol structures such a recursion, co-routines,hierarchical parallelism, futures [Baker and Hewitt 1977],
etc
. can be implemented.Messages in the Actor model are analogous to packets inInternet computing in that they need not be received in theorder sent. Not providing the order of delivery guaranteeallows packet switching to buffer packets, use multiplepaths to send packets, resend damaged packets, and toprovide other optimizations.For example, Actors are allowed to pipeline the processingof messages. What this means is that in the course of processing a message
m1
, an Actor can designate thebehavior to be used to process the next message, and thenin fact begin processing another message
m2
before it hasfinished processing
m1
. Just because an Actor is allowedto pipeline the processing of messages does not mean thatit
must
pipeline the processing. Whether a message ispipelined is an engineering tradeoff.
Locality and Security
Another important characteristic of the Actor model islocality. Locality means that in processing a message: anActor can send messages only to addresses for which it hasinformation by the following means:1.
that it receives in the message2.
that it already had before it received the message3.
that it creates while processing the message.In the Actor model, there is no simultaneous change inmultiple locations. In this way it differs from some othermodels of concurrency,
e.g.
, the Petri net model in whichtokens are simultaneously removed from multiple locationsand placed in other locations.The security of Actors can be protected in the followingways:
hardwiring in which Actors are physicallyconnected
tagged memory as in Lisp machines,
etc.
virtual machines as in Java virtual machine,Common Language Runtime,
etc.
signing and/or encryption of Actors and theiraddressesA delicate point in the Actor model is the ability tosynthesize the address of an Actor. In some cases securitycan be used to prevent the synthesis of addresses.However, if an Actor address is simply a bit string thenclearly it can be synthesized given eons of time although itcan be made unguessable in practice if the bit strings arelong enough.
Computational Representation Theorem
There is a
Computational Representation Theorem
in theActor model for systems which are closed in the sense thatthey do not receive communications from outside. Aclosed system is defined to be one which does notcommunicate with the outside.Actor model theory provides the means to characterize all the possiblecomputations of a closed system in terms of theComputational Representation Theorem [Clinger 1981;Hewitt 2006]:The denotation
Denote
S
of a closed system
S
representsall the possible behaviors of
S
as
Denote
S
=
⊔
i
ω
Progression
S
i
(
⊥
S
)
where
Progression
S
is an approximation function thattakes a set of partial behaviors to their next stage and
⊥
S
is the initial behavior of
S
.
In this way, the behavior of
S
can be mathematicallycharacterized in terms of all its possible behaviors(including those involving unbounded nondeterminism).Although
Denote
S
is not an implementation of
S
, it can beused to prove a generalization of the Church-Turing-Rosser-Kleene thesis [Kleene 1943]:
Enumeration Theorem
: If the primitive Actors of aclosed Actor System
S
are effective, then the possibleoutputs of
S
are recursively enumerable.
Proof
: Follows immediately from theRepresentation Theorem.The upshot is that
concurrent systems can be represented and characterized by logical deduction but cannot be implemented
. Thus, the followingpractical problem arose:How can practical programming languages berigorously defined since the proposal by Scott andStrachey [1971] to define them in terms lambdacalculus failed because the lambda calculus cannotimplement concurrency?
Search History:
Result 00 of 00
00 results for result for
p.
Illustrations for ActorScriptTM
ActorScriptTM:
Industrial strength integration of local and nonlocal concurrency
for Client-cloud Computing
Carl Hewitt
http://carlhewitt.info
Industrial strength integration of local and nonlocal concurrency
for Client-cloud Computing
Carl Hewitt
http://carlhewitt.info
1.7K
Reads
2
Readcasts
1
Embed Views
Get Scribd Mobile
To get Scribd mobile enter your number and we'll send you a link to the Scribd app for iPhone & Android.We've sent a link to the Scribd app. If you didn't receive it, try again.
We'll never share your phone number.
More From This User
Notes
Load more
