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/07 20:20] – added tvcutsem | at:tutorial:actors [2007/06/19 16:12] – tvcutsem | ||
---|---|---|---|
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 15: | ||
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 ==== | + | ===== Actors and Far References |
In AmbientTalk, | In AmbientTalk, | ||
Line 34: | Line 34: | ||
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 disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below. | 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 disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below. | ||
- | ==== Asynchronous Message Sending ==== | + | 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 // |
+ | |||
+ | ===== Asynchronous Message Sending | ||
AmbientTalk, | AmbientTalk, | ||
Line 87: | Line 89: | ||
</ | </ | ||
- | ==== Isolates ==== | + | ===== 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. | 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. | ||
Line 105: | Line 107: | ||
}; | }; | ||
}; | }; | ||
- | >>< | + | >>< |
</ | </ | ||
- | The '' | + | The '' |
An isolate differs from a regular object as follows: | An isolate differs from a regular object as follows: | ||
Line 130: | Line 132: | ||
</ | </ | ||
- | < | + | < |
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 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' | ||
< | < | ||
Line 163: | Line 165: | ||
</ | </ | ||
- | ==== 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 to reconcile return values with asynchronous message sends is the notion of a [[Wp> | ||
Line 177: | Line 179: | ||
</ | </ | ||
- | === 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 // | 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 // | ||
Line 190: | Line 192: | ||
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 '' | ||
- | === Working with Unresolved Futures === | + | ==== Working with Unresolved Futures |
We have yet to describe what objects can do with futures that are // | We have yet to describe what objects can do with futures that are // | ||
Line 204: | Line 206: | ||
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 === | + | ==== 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 274: | Line 276: | ||
When the future for ''< | When the future for ''< | ||
- | === Futures and Striped Messages === | + | ==== Futures and Striped Messages |
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 '' | ||
Line 292: | Line 294: | ||
Finally, it is possible to first invoke '' | Finally, it is possible to first invoke '' | ||
- | === Conditional Synchronisation with Futures === | + | ==== 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: | 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: | ||
Line 307: | Line 309: | ||
The resolver also defines a '' | The resolver also defines a '' | ||
- | ==== Actor Mirrors ==== | + | ===== 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 '' | 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 '' | ||
Line 330: | Line 332: | ||
Other methods that can be overridden are '' | Other methods that can be overridden are '' | ||
- | ==== Nesting Actors ==== | + | ===== Nesting Actors |
In AmbientTalk, | In AmbientTalk, | ||
Line 349: | Line 351: | ||
If both the '' | If both the '' | ||
- | Recall that isolates could be given selective access to their enclosing lexical scope by creating a local copy of the variable. We allow actors to do the same. Hence, the above example can be written properly as: | + | Recall that isolates could be given selective access to their enclosing lexical scope by specifying accessed variables as formal parameters to their initializing closure, which gave rise to copying |
< | < | ||
Line 364: | Line 366: | ||
</ | </ | ||
- | Hence, it still makes sense to nest actors, but each actor will operate on its own local copy of the variable. Furthermore, | + | 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