at:tutorial:actors
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
at:tutorial:actors [2007/05/15 19:35] – * tvcutsem | at:tutorial:actors [2020/02/05 21:26] (current) – elisag | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | < | ||
- | |||
====== Concurrent Programming with Actors ====== | ====== Concurrent Programming with Actors ====== | ||
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 |
+ | |||
+ | < | ||
+ | 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 // | ||
+ | </ | ||
+ | |||
+ | The figure | ||
- | Note that, if the object referred to by a far reference is striped with one or more stripes, the far reference itself is striped with the same stripes. Hence, an object located on a remote actor can be tested for its stripes // | + | {{ : |
===== Asynchronous Message Sending ===== | ===== Asynchronous Message Sending ===== | ||
Line 65: | Line 69: | ||
}; | }; | ||
}; | }; | ||
- | >>< | + | >>< |
</ | </ | ||
Line 93: | Line 97: | ||
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. | 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 // | + | 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 // |
< | < | ||
Line 107: | Line 111: | ||
}; | }; | ||
}; | }; | ||
- | >>< | + | >>< |
</ | </ | ||
- | The '' | + | The '' |
An isolate differs from a regular object as follows: | An isolate differs from a regular object as follows: | ||
Line 132: | Line 136: | ||
</ | </ | ||
- | < | + | < |
- | A word of warning: isolates | + | Isolates |
< | < | ||
def ==(other) { | def ==(other) { | ||
Line 139: | Line 143: | ||
} | } | ||
</ | </ | ||
+ | |||
+ | On a related note, it is good practice to consider isolates as // | ||
</ | </ | ||
- | It is important to note that an isolate has no access whatsoever to its encompassing scope. | + | As already explained, |
< | < | ||
Line 154: | Line 160: | ||
</ | </ | ||
- | Sometimes | + | However, sometimes |
< | < | ||
Line 164: | Line 170: | ||
>>4 | >>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 ===== | ===== Futures ===== | ||
- | As you may have noticed previously, asynchronous message sends do not return any value (that is, they return '' | + | As you may have noticed previously, asynchronous message sends do not return any value (that is, they return '' |
+ | |||
+ | |||
==== The Concept ==== | ==== The Concept ==== | ||
- | The most well-known language feature to reconcile return values with asynchronous message sends is the notion of a [[Wp> | + | The most well-known language feature |
+ | |||
+ | 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: | Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows: | ||
Line 178: | Line 193: | ||
def sum := calculator< | def sum := calculator< | ||
</ | </ | ||
+ | |||
==== Enabling futures ==== | ==== Enabling futures ==== | ||
- | Futures are a frequently recurring language feature in concurrent and distributed languages (for example, in ABCL, the actor-based concurrent language). They are also commonly known by the name of // | + | In AmbientTalk, |
To enable futures, it suffices to import the futures module and to enable it, as follows: | To enable futures, it suffices to import the futures module and to enable it, as follows: | ||
Line 190: | Line 206: | ||
</ | </ | ||
- | 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 '' | + | 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 '' |
+ | |||
+ | < | ||
+ | In what follows we provide an overview on how to work with futures. More information pertaining to the API of the futures language module can be found in the [[: | ||
+ | </ | ||
==== Working with Unresolved Futures ==== | ==== Working with Unresolved Futures ==== | ||
- | We have yet to describe what objects can do with futures that are // | + | 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, of course. In the actor paradigm where communication between actors should remain strictly asynchronous, | + | 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:// | + | The solution proposed in the [[http:// |
- | < | + | As an example |
- | 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. | + | < |
+ | def booleanFuture := remoteObject< | ||
+ | booleanFuture< | ||
+ | | ||
+ | } ifFalse: { | ||
+ | ... | ||
+ | } | ||
+ | </ | ||
- | AmbientTalk only allows one method to be synchronously invoked on a future, the '' | + | In this example, the message |
==== Working with Resolved Futures ==== | ==== 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: | 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: | ||
Line 245: | Line 278: | ||
</ | </ | ||
- | Or, you can specify a stripe | + | Or, you can specify a type tag to only catch specific exceptions: |
< | < | ||
Line 266: | Line 299: | ||
</ | </ | ||
- | Finally, it is useful to know that '' | + | Finally, it is useful to know that '' |
< | < | ||
Line 274: | Line 307: | ||
</ | </ | ||
- | When the future for ''< | + | When the future for ''< |
- | ==== Futures and Striped | + | ==== Futures and Annotated |
- | As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking '' | + | As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking '' |
- | When a message send is striped | + | When a message send is annotated |
< | < | ||
- | o<-m()@OneWayMessage | + | o<-m()@OneWay |
</ | </ | ||
- | When a message send is striped | + | When a message send is annotated |
< | < | ||
- | o<-m()@FutureMessage | + | o<-m()@TwoWay |
</ | </ | ||
+ | |||
+ | When a message send is annotated with the '' | ||
+ | |||
+ | < | ||
+ | o< | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | More details about the '' | ||
+ | </ | ||
Finally, it is possible to first invoke '' | Finally, it is possible to first invoke '' | ||
Line 299: | Line 342: | ||
< | < | ||
+ | // to create an explicit future: | ||
def [future, resolver] := makeFuture(); | def [future, resolver] := makeFuture(); | ||
- | consumer< | + | |
- | def val := /* calculate useful value */ | + | // to explicitly resolve a future |
resolver.resolve(val); | resolver.resolve(val); | ||
</ | </ | ||
Line 308: | Line 352: | ||
The resolver also defines a '' | 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 ===== | ===== Actor Mirrors ===== | ||
Line 313: | Line 447: | ||
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 '' | 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, | + | Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, |
- | Overriding the actor' | + | Overriding the actor' |
< | < | ||
- | def oldmirror := actor.install: (extend: actor with: { | + | def actor := reflectOnActor(); |
+ | def oldmirror := actor.becomeMirroredBy: (extend: actor with: { | ||
def send(msg) { | def send(msg) { | ||
log(msg); | log(msg); | ||
Line 326: | Line 461: | ||
</ | </ | ||
- | Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent' | + | 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 '' | For a good use case of actor mirrors, see the '' | ||
+ | </ | ||
Other methods that can be overridden are '' | Other methods that can be overridden are '' | ||
Line 349: | Line 486: | ||
</ | </ | ||
- | If both the '' | + | If both the '' |
- | Recall that isolates could be given selective | + | Recall that isolates could be given access to their enclosing lexical scope either |
< | < |
at/tutorial/actors.1179250526.txt.gz · Last modified: 2007/06/19 16:11 (external edit)