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/06/19 16:12] – tvcutsem | at:tutorial:actors [2007/07/18 11:21] – elisag | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | < | ||
====== Concurrent Programming with Actors ====== | ====== Concurrent Programming with Actors ====== | ||
Line 15: | Line 14: | ||
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 32: | Line 31: | ||
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 |
- | Note that, 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 // | + | < |
+ | 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 below summarizes AmbientTalk' | ||
+ | |||
+ | {{ : | ||
===== Asynchronous Message Sending ===== | ===== Asynchronous Message Sending ===== | ||
Line 93: | Line 98: | ||
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 132: | Line 137: | ||
</ | </ | ||
- | < | + | < |
- | A word of warning: isolates are objects that are 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' | + | A word of warning: isolates are objects that are (deep) |
< | < | ||
def ==(other) { | def ==(other) { | ||
Line 141: | Line 146: | ||
</ | </ | ||
- | It is important to note that an isolate has no access whatsoever to its encompassing scope. | + | As already explained, |
< | < | ||
Line 154: | Line 159: | ||
</ | </ | ||
- | Sometimes | + | However, sometimes |
< | < | ||
Line 167: | Line 172: | ||
===== 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 |
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 181: | Line 186: | ||
==== 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 194: | Line 199: | ||
==== 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, of course. In the actor paradigm where communication between actors should remain strictly asynchronous, | ||
- | The solution proposed in the [[http:// | + | The solution proposed in the [[http:// |
- | < | + | ==== 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. | 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 '' | AmbientTalk only allows one method to be synchronously invoked on a future, the '' | ||
- | + | </ | |
- | ==== Working with Resolved Futures ==== | + | |
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 250: | ||
</ | </ | ||
- | Or, you can specify a stripe | + | Or, you can specify a type tag to only catch specific exceptions: |
< | < | ||
Line 266: | Line 271: | ||
</ | </ | ||
- | Finally, it is useful to know that '' | + | Finally, it is useful to know that '' |
< | < | ||
Line 274: | Line 279: | ||
</ | </ | ||
- | 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 |
< | < | ||
Line 286: | Line 291: | ||
</ | </ | ||
- | When a message send is striped | + | When a message send is annotated |
< | < |
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag