Differences

This shows you the differences between two versions of the page.

--- at:tutorial:actors [2007/06/19 16:13] – tvcutsem
+++ at:tutorial:actors [2007/07/18 09:12] – Adding elisag
@@ Line 32: / Line 32: @@
 As you can see, actors are created similar to objects. The ''actor:'' method, defined in the global lexical scope, takes a closure as its sole argument and uses that closure to initialize the behaviour of the new actor. The creator of the actor immediately receives a so-called //far reference// to this behaviour object, and from that moment on the creating actor and the created actor run in parallel, each capable of processing incoming messages autonomously.
-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 only allow asynchronous access to the referenced object. This is enforced by the kind of messages that these references can carry, as will be further explained in the next section.
+<note>
+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 //synchronously//, there is no need to communicate with the remote actor, as the far reference itself includes type tag information.
+</note>
+The figure below summarizes AmbientTalk's concurrency model where actors are represented as communicating event loops. The dotted lines represent the event loop threads of the actors which perpetually take messages from their message queue and synchronously execute the corresponding methods on the actor's owned objects. An event loop thread never ``escapes'' its actor boundary. When communication with an object in another actor is required, a message is sent asynchronously via a far reference to the object. For example, as shown in the figure, when A sends a message to B, the message is enqueued in the message queue of B's actor which eventually processes it.
+{{:at:tutorial:concurrencymodel.png?450|:at:tutorial:concurrencymodel.png}}
-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 //synchronously//, there is no need to communicate with the remote actor, as the far reference itself includes type tag information.
 ===== Asynchronous Message Sending =====
@@ Line 276: / Line 284: @@
 When the future for ''<-add(1,2)'' becomes resolved with ''sum'', the ''fut'' future will be resolved with the future for the ''<-add(sum,3)'' message. When that message finally returns yet another sum, that sum will become the value of ''fut''.
-==== Futures and Striped Messages ====
+==== Futures and Annotated Messages ====
-As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking ''enableFutures(true)'' makes asynchronous sends return a future by default. Invoking ''enableFutures(false)'' returns ''nil'' by default. No matter how you enabled futures, you can always override the default setting by explicitly //annotating// the message send itself by means of two stripes exported by the futures module, as explained below.
+As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking ''enableFutures(true)'' makes asynchronous sends return a future by default. Invoking ''enableFutures(false)'' returns ''nil'' by default. No matter how you enabled futures, you can always override the default setting by explicitly //annotating// the message send itself by means of two type tags exported by the futures module, as explained below.
-When a message send is striped with the ''OneWayMessage'' stripe, it will never attach a future to the message. This is primarily useful if you have enabled futures by default, but want to send a one-way message requiring no result. In this case, simply send the message as follows:
+When a message send is annotated with the ''OneWayMessage'' type tag, it will never attach a future to the message. This is primarily useful if you have enabled futures by default, but want to send a one-way message requiring no result. In this case, simply send the message as follows:
 <code>
@@ Line 286: / Line 294: @@
 </code>
-When a message send is striped with the ''FutureMessage'' stripe, a future is attached to the message, but //only if futures have been enabled//! This is primarily useful if you have enabled futures, but not by default, because you don't want to incur the overhead of future-type message sends on each of the messages sent. In cases where futures become useful, simply send the message as follows:
+When a message send is annotated with the ''FutureMessage'' type tag, a future is attached to the message, but //only if futures have been enabled//! This is primarily useful if you have enabled futures, but not by default, because you don't want to incur the overhead of future-type message sends on each of the messages sent. In cases where futures become useful, simply send the message as follows:
 <code>