at:tutorial:actors
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
at:tutorial:actors [2008/08/01 14:44] – * tvcutsem | at:tutorial:actors [2020/02/05 21:26] – elisag | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | |||
====== Concurrent Programming with Actors ====== | ====== Concurrent Programming with Actors ====== | ||
Line 70: | Line 69: | ||
}; | }; | ||
}; | }; | ||
- | >>< | + | >>< |
</ | </ | ||
Line 138: | Line 137: | ||
<note warning> | <note warning> | ||
- | A word of warning: isolates | + | Isolates |
< | < | ||
def ==(other) { | def ==(other) { | ||
Line 144: | Line 143: | ||
} | } | ||
</ | </ | ||
+ | |||
+ | On a related note, it is good practice to consider isolates as // | ||
</ | </ | ||
Line 169: | 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 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> | + | 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: | Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows: | ||
Line 185: | Line 195: | ||
==== Enabling futures ==== | ==== Enabling futures ==== | ||
- | |||
- | 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 195: | Line 203: | ||
</ | </ | ||
- | 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 '' |
- | More information pertaining to the API of the futures language module can be found in the [[: | + | < |
+ | In what follows we provide an overview on how to work with futures. | ||
+ | </ | ||
==== Working with Unresolved Futures ==== | ==== Working with Unresolved Futures ==== | ||
Line 300: | Line 310: | ||
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 annotated with the '' | + | When a message send is annotated with the '' |
< | < | ||
- | o<-m()@OneWayMessage | + | o<-m()@OneWay |
</ | </ | ||
- | When a message send is annotated with the '' | + | When a message send is annotated with the '' |
< | < | ||
- | 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 319: | Line 339: | ||
< | < | ||
+ | // 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 328: | Line 349: | ||
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 372: | Line 483: | ||
</ | </ | ||
- | 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.txt · Last modified: 2020/02/05 21:26 by elisag