at:tutorial:actors
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
at:tutorial:actors [2007/04/01 11:54] – finished tvcutsem | at:tutorial:actors [2020/02/05 21:17] – moving elisag | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | < | + | ====== Concurrent Programming with Actors |
- | + | ||
- | ===== Concurrent Programming with Actors ===== | + | |
Concurrency is an integral part of the AmbientTalk programming language. Rather than relying on [[wp> | Concurrency is an integral part of the AmbientTalk programming language. Rather than relying on [[wp> | ||
- | === Threads vs Actors === | + | ===== Threads vs Actors |
In traditional programming languages, the control flow of a concurrent program is divided over a number of threads. Each thread operates concurrently and control can switch from one thread to another non-deterministically. If two threads have access to the same data (objects), they might cause erroneous behaviour (so-called //race conditions// | In traditional programming languages, the control flow of a concurrent program is divided over a number of threads. Each thread operates concurrently and control can switch from one thread to another non-deterministically. If two threads have access to the same data (objects), they might cause erroneous behaviour (so-called //race conditions// | ||
Line 15: | Line 13: | ||
Generally speaking, an active object is an object that encapsulates its own thread of control. An active object also has a message queue or mailbox from which it processes incoming messages. Each message is processed sequentially. An active object responds to an incoming message by invoking the method corresponding to the message. The method is executed by the active object' | Generally speaking, an active object is an object that encapsulates its own thread of control. An active object also has a message queue or mailbox from which it processes incoming messages. Each message is processed sequentially. An active object responds to an incoming message by invoking the method corresponding to the message. The method is executed by the active object' | ||
- | === Actors and Far References === | + | ===== AmbientTalk |
In AmbientTalk, | In AmbientTalk, | ||
Line 27: | Line 25: | ||
}; | }; | ||
}; | }; | ||
- | >>< | + | >>< |
</ | </ | ||
As you can see, actors are created similar to objects. The '' | As you can see, actors are created similar to objects. The '' | ||
- | So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references | + | So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references |
- | === Asynchronous Message Sending === | + | < |
+ | If the object referred to by a far reference is tagged with one or more type tags, the far reference itself is tagged with the same type tags. Hence, an object located on a remote actor can be tested for its types // | ||
+ | </ | ||
- | === Isolates === | + | The figure below summarizes AmbientTalk' |
+ | |||
+ | {{ : | ||
+ | |||
+ | ===== Asynchronous Message Sending ===== | ||
+ | |||
+ | AmbientTalk, | ||
+ | |||
+ | Far references, like the reference stored in the variable '' | ||
+ | |||
+ | Hence, given the example above, the method '' | ||
+ | |||
+ | < | ||
+ | > | ||
+ | >> | ||
+ | </ | ||
+ | |||
+ | The above code is simple enough to understand: the '' | ||
+ | |||
+ | But what happens when the method to invoke asynchronously has parameters that need to be passed. How does parameter passing work in the context of inter-actor message sending? The rules are simple enough: | ||
+ | - Objects and closures are always passed **by far reference** | ||
+ | - Native data types like numbers, text, tables, ... are always passed **by copy** | ||
+ | |||
+ | Generally speaking, any object that encapsulates a lexical scope is passed by reference, because passing such an object by copy would entail passing the entire lexical scope by copy - a costly operation. Objects without a lexical scope, such as methods, can be copied without having to recursively copy any scope. | ||
+ | |||
+ | When an object is passed by reference, we mean that the formal parameter of a method will be bound to a far reference to the original object. When it is passed by copy, the formal parameter will be bound to a local copy of the object. For example, consider the following '' | ||
+ | |||
+ | < | ||
+ | >def calculator := actor: { | ||
+ | def add(x, | ||
+ | customer< | ||
+ | }; | ||
+ | }; | ||
+ | >>< | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | < | ||
+ | > | ||
+ | def result(sum) { | ||
+ | system.println(" | ||
+ | }; | ||
+ | }); | ||
+ | >> | ||
+ | </ | ||
+ | |||
+ | Because of the parameter passing rules described above, the '' | ||
+ | |||
+ | < | ||
+ | sum = 3 | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | The parameter passing semantics just described lead to a model where the only references that cross actor boundaries are far references. In combination with the message sending semantics described previously, this guarantees that asynchronous messages are the only type of messages that can cross actor boundaries, ensuring that concurrent (and as will be shown later, also distributed) communication is strictly asynchronous. In such a model, deadlocks cannot occur (an actor is never blocked) and race conditions within one single actor can never occur. These properties significantly reduce the complexity of concurrent programs. | ||
+ | </ | ||
+ | |||
+ | ===== Isolates ===== | ||
+ | |||
+ | The parameter passing semantics defined above rule out any possibility for an object to be passed by copy. The reason for this semantics is that objects encapsulate a lexical scope, and parameter passing an object by copy would require the entire lexical scope to be parameter-passed as well. | ||
+ | |||
+ | To enable objects to be passed by copy between actors, a special type of objects is introduced. These objects are called **isolates** because they are // | ||
+ | |||
+ | < | ||
+ | >def complexNumber := isolate: { | ||
+ | def re; // assume cartesian coordinates | ||
+ | def im; | ||
+ | def init(re,im) { | ||
+ | self.re := re; | ||
+ | self.im := im; | ||
+ | }; | ||
+ | def +(other) { | ||
+ | self.new(re+other.re, | ||
+ | }; | ||
+ | }; | ||
+ | >>< | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | An isolate differs from a regular object as follows: | ||
+ | - it has **no** access to its surrounding lexical scope; this means that an isolate only has access to its local fields and methods. An isolate does have access to the global lexical scope of its actor. | ||
+ | - it is parameter-passed by-copy rather than by-reference in inter-actor message sends. The copy of the isolate received by the remote actor can only access that actor' | ||
+ | - external method definitions on isolates are disallowed. The reason for this is that external method definitions implicitly carry a lexical scope (the scope of their definition). Hence, if an isolate with external methods has to be copied, those scopes would have to be copied as well. Following the rule that objects | ||
+ | |||
+ | Returning to the calculator example, the calculator can now add complex numbers locally and send (a copy of) the resulting complex number back to the customer: | ||
+ | |||
+ | < | ||
+ | > | ||
+ | complexNumber.new(1, | ||
+ | complexNumber.new(2, | ||
+ | object: { | ||
+ | def result(sum) { | ||
+ | system.println(" | ||
+ | }; | ||
+ | }); | ||
+ | >> | ||
+ | sum=(3,3) | ||
+ | </ | ||
+ | |||
+ | <note warning> | ||
+ | Isolates are objects that are (deep) copied freely between actors. As a result, they should be objects whose actual object identity is of little importance. Usually, the identity of by-copy objects is determined by the value of some of the object' | ||
+ | < | ||
+ | def ==(other) { | ||
+ | (re == other.re).and: | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | On a related note, it is good practice to consider isolates as // | ||
+ | </ | ||
+ | |||
+ | As already explained, an isolate has no access whatsoever to its encompassing scope. Hence, the following code results in an exception: | ||
+ | |||
+ | < | ||
+ | >def x := 1; | ||
+ | def adder := isolate: { | ||
+ | def add(n) { x + n }; | ||
+ | }; | ||
+ | adder.add(3) | ||
+ | >> | ||
+ | origin: | ||
+ | at adder.add(3) | ||
+ | </ | ||
+ | |||
+ | However, sometimes it is useful to initialize an isolate with the values of lexically visible variables. To this end, AmbientTalk allows the programmer to specify which lexical variables should be //copied into// the isolate itself, such that the isolate has its own, local copy of the variable. Lexical variables that need to be copied like this are specified as formal parameters to the closure passed to the '' | ||
+ | |||
+ | < | ||
+ | >def x := 1; | ||
+ | def adder := isolate: { |x| | ||
+ | def add(n) { x + n }; | ||
+ | }; | ||
+ | adder.add(3) | ||
+ | >>4 | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | Since AmbientTalk 2.12 the interpreter is smart enough to figure out the lexically free variables of an isolate itself. If no variables are explicitly listed, the interpreter will try to figure out which lexically free variables it should implicitly copy. Unlike explicitly listed variables (like '' | ||
+ | </ | ||
+ | |||
+ | ===== Futures ===== | ||
+ | |||
+ | As you may have noticed previously, asynchronous message sends do not return any value (that is, they return '' | ||
+ | |||
+ | ==== The Concept ==== | ||
+ | |||
+ | The most well-known language feature in concurrent and distributed languages (for example, in ABCL, the actor-based concurrent language) to reconcile return values with asynchronous message sends is the notion of a [[Wp> | ||
+ | |||
+ | Futures are objects that represent return values that may not yet have been computed. Once the asynchronously invoked method has completed, the future is replaced with the actual return value, and objects that referred to the future transparently refer to the return value. | ||
+ | |||
+ | Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows: | ||
+ | |||
+ | < | ||
+ | def sum := calculator< | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Enabling futures ==== | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | To enable futures, it suffices to import the futures module and to enable it, as follows: | ||
+ | |||
+ | < | ||
+ | import / | ||
+ | enableFutures(true); | ||
+ | </ | ||
+ | |||
+ | The first statement imports the futures module into the current lexical scope. This enables you as a developer to use some additional language constructs exported by the futures module, as will be explained later. The second statement enables the futures behaviour, causing any asynchronous message send to return a future rather than '' | ||
+ | |||
+ | ==== Working with Unresolved Futures ==== | ||
+ | |||
+ | We have described a future as a placeholder for the return value of an asynchronous message send which is eventually // | ||
+ | |||
+ | Blocking a thread on a future can be a major source of deadlocks, like any form of blocking. In the actor paradigm where communication between actors should remain strictly asynchronous, | ||
+ | |||
+ | The solution proposed in the [[http:// | ||
+ | |||
+ | As an example of a pipeline of message sends, consider the following code: | ||
+ | |||
+ | < | ||
+ | def booleanFuture := remoteObject< | ||
+ | booleanFuture< | ||
+ | ... | ||
+ | } ifFalse: { | ||
+ | ... | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | In this example, the message '' | ||
+ | |||
+ | ==== Working with Resolved Futures ==== | ||
+ | |||
+ | When a future eventually becomes resolved with a value, any messages that were accumulated by the future are forwarded asynchronously to the actual return value, such that it appears as if the original object had sent the messages to the actual return value in the first place. | ||
+ | |||
+ | <note important> | ||
+ | AmbientTalk only allows one method to be synchronously invoked on a future, the '' | ||
+ | </ | ||
+ | |||
+ | As explained above, it is always correct to use asynchronous message sends to communicate with a future. Sometimes, however, we may want to perform some operation on the return value other than message sending, for example, printing it to the screen. If you print the future directly, you get the following: | ||
+ | |||
+ | < | ||
+ | def sum := calculator< | ||
+ | system.println(sum); | ||
+ | >> < | ||
+ | </ | ||
+ | |||
+ | AmbientTalk prints the future to the screen. At a later point in time, printing the future again may result in the following: | ||
+ | |||
+ | < | ||
+ | > | ||
+ | >> < | ||
+ | </ | ||
+ | |||
+ | This time, the future was printed when the return value was computed. But what if we simply want to inform the user of the actual value of '' | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | < | ||
+ | def sumFuture := calculator< | ||
+ | when: sumFuture becomes: { |sum| | ||
+ | system.println(" | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The first argument to '' | ||
+ | |||
+ | < | ||
+ | def sumFuture := calculator< | ||
+ | when: sumFuture becomes: { |sum| | ||
+ | system.println(" | ||
+ | } catch: { |exc| | ||
+ | system.println(" | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | Or, you can specify a type tag to only catch specific exceptions: | ||
+ | |||
+ | < | ||
+ | def divFuture := calculator< | ||
+ | when: divFuture becomes: { |div| | ||
+ | system.println(" | ||
+ | } catch: DivisionByZero using: { |exc| | ||
+ | system.println(" | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | < | ||
+ | when: sumFuture becomes: { |sum| | ||
+ | system.println(" | ||
+ | }; | ||
+ | system.print(" | ||
+ | >> | ||
+ | </ | ||
+ | |||
+ | Finally, it is useful to know that '' | ||
+ | |||
+ | < | ||
+ | def fut := when: calculator< | ||
+ | calculator< | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | When the future for ''< | ||
+ | |||
+ | ==== Futures and Annotated Messages ==== | ||
+ | |||
+ | As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking '' | ||
+ | |||
+ | When a message send is annotated with the '' | ||
+ | |||
+ | < | ||
+ | o< | ||
+ | </ | ||
+ | |||
+ | When a message send is annotated with the '' | ||
+ | |||
+ | < | ||
+ | o< | ||
+ | </ | ||
+ | |||
+ | When a message send is annotated with the '' | ||
+ | |||
+ | < | ||
+ | o< | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | More details about the '' | ||
+ | </ | ||
+ | |||
+ | Finally, it is possible to first invoke '' | ||
+ | |||
+ | ==== Conditional Synchronisation with Futures ==== | ||
+ | |||
+ | Futures are useful to synchronise on the return value of an asynchronous message send. However, objects hosted by different actors may often want to synchronise based on other events or conditions. In such cases, futures can be created and resolved explicitly. The interface to the programmer is about the same as that specified by the E language: | ||
+ | |||
+ | < | ||
+ | // to create an explicit future: | ||
+ | def [future, resolver] := makeFuture(); | ||
+ | |||
+ | // to explicitly resolve a future | ||
+ | resolver.resolve(val); | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The resolver also defines a '' | ||
+ | |||
+ | As an example of such conditional synchronization, | ||
+ | |||
+ | < | ||
+ | def makeDatingService() { | ||
+ | def people := []; // a list of Questionnaire objects | ||
+ | object: { | ||
+ | def match(lonelyHeart) { | ||
+ | // if an ideal mate is found in the list, | ||
+ | // | ||
+ | // otherwise | ||
+ | // | ||
+ | // the lonelyHeart later, when an ideal made | ||
+ | // has registered with the dating service | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Let us assume that a person is simply identified by a name and its sex: | ||
+ | < | ||
+ | def makePerson(nam, | ||
+ | object: { | ||
+ | def name := nam; | ||
+ | def sex := sx; | ||
+ | } | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The dating service has a little database stored as a simple list. This list does not contain person objects but rather Questionnaire objects. The questionnaire contains the logic necessary to match people. We will assume for the sake of the example that 2 people match if they are of the opposite sex. In addition, a questionnaire object can keep track of an " | ||
+ | |||
+ | < | ||
+ | def makeQuestionnaire(p) { | ||
+ | def idealPersonResolver; | ||
+ | object: { | ||
+ | def person := p; | ||
+ | def matches(otherQ) { otherQ.person.sex != p.sex }; | ||
+ | def wait() { | ||
+ | def [future, resolver] := makeFuture(); | ||
+ | idealPersonResolver := resolver; | ||
+ | future | ||
+ | }; | ||
+ | def notify(name) { idealPersonResolver.resolve(name) }; | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | When a questionnaire is asked to '' | ||
+ | |||
+ | Armed with these abstractions, | ||
+ | |||
+ | < | ||
+ | def makeDatingService() { | ||
+ | def people := []; // a list of Questionnaire objects | ||
+ | object: { | ||
+ | def match(lonelyHeart) { | ||
+ | def lonelyHeartQ := makeQuestionnaire(lonelyHeart); | ||
+ | { |return| | ||
+ | people.each: | ||
+ | // an ideal mate was found | ||
+ | if: (idealMateQ.matches(lonelyHeartQ).and: | ||
+ | idealMateQ.notify(lonelyHeart.name); | ||
+ | // remove the person from the database | ||
+ | people := people.filter: | ||
+ | return(idealMateQ.person.name) // notify lonelyHeart | ||
+ | } | ||
+ | }; | ||
+ | // no ideal mate was found, store its questionnaire in the database | ||
+ | people := people + [lonelyHeartQ]; | ||
+ | lonelyHeartQ.wait(); | ||
+ | }.escape(); | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Below, we define an auxiliary method that illustrates how a lonely heart has to interact with the dating service. | ||
+ | |||
+ | < | ||
+ | def d := makeDatingService(); | ||
+ | def register(p) { | ||
+ | when: d< | ||
+ | system.println(p.name + " matched with " + name); | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The key to our conditional synchronization is that the '' | ||
+ | |||
+ | The complete source code of the above example can be found in the file '' | ||
+ | |||
+ | ===== Actor Mirrors ===== | ||
+ | |||
+ | An actor in AmbientTalk is primarily a //host// for regular objects. It is equipped with a message queue to receive asynchronous messages sent to one of its objects. The mirrors on these objects have corresponding meta-level operations such as '' | ||
+ | |||
+ | Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, | ||
+ | |||
+ | Overriding the actor' | ||
+ | |||
+ | < | ||
+ | def actor := reflectOnActor(); | ||
+ | def oldmirror := actor.becomeMirroredBy: | ||
+ | def send(msg) { | ||
+ | log(msg); | ||
+ | super^send(msg); | ||
+ | }; | ||
+ | }); | ||
+ | </ | ||
+ | |||
+ | Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent' | ||
+ | |||
+ | < | ||
+ | For a good use case of actor mirrors, see the '' | ||
+ | </ | ||
+ | |||
+ | Other methods that can be overridden are '' | ||
+ | |||
+ | ===== Nesting Actors ===== | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | < | ||
+ | def outer := actor: { | ||
+ | def x := 1; | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | |||
+ | def inner := actor: { | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | If both the '' | ||
+ | |||
+ | Recall that isolates could be given access to their enclosing lexical scope either by specifying accessed variables as formal parameters to their initializing closure or by having the interpreter derive the lexically free variables automatically. If the programmer wants to make explicit the fact that '' | ||
+ | |||
+ | < | ||
+ | def outer := actor: { | ||
+ | def x := 1; | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | |||
+ | def inner := actor: { |x| | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
- | === Actor Mirrors === | + | It still makes sense to nest actors, but each actor will have its own local copy of lexically shared variables. Furthermore, |
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag