Differences

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

--- at:tutorial:actors [2007/04/01 12:21] – added tvcutsem
+++ at:tutorial:actors [2007/04/06 20:00] – added tvcutsem
@@ Line 50: / Line 50: @@
 But what happens when the method to invoke asynchronously has parameters that need to be passed. How does parameter passing work in the context of inter-actor message sending? The rules are simple enough:
-  - Objects are always passed **by reference**
+  - Objects and closures are always passed **by reference**
-  - Native data types like numbers,text,tables are always passed **by copy**
+  - Native data types like numbers, text, tables, ... are always passed **by copy**
+Generally speaking, any object that encapsulates a lexical scope is passed by reference, because passing such an object by copy would entail passing the entire lexical scope by copy - a costly operation. Objects without a lexical scope, such as methods, can be copied without having to recursively copy any scope.
 When an object is passed by reference, we mean that the formal parameter of a method will be bound to a far reference to the original object. When it is passed by copy, the formal parameter will be bound to a local copy of the object. For example, consider the following ''calculator'' actor:
 <code>
->>def calculator := actor: {
+>def calculator := actor: {
   def add(x,y,customer) {
     customer<-result(x+y)
   };
 };
-><far ref to:<object:11600335>>
+>><far ref to:<object:11600335>>
 </code>
@@ Line 67: / Line 69: @@
 <code>
->>calculator<-add(1,2,object: {
+>calculator<-add(1,2,object: {
   def result(sum) {
     system.println("sum = " + sum);
   };
-};
+});
->nil
+>>nil
 </code>
-Because of the parameter passing rules described above, the ''add'' method will receive copies of the numbers ''1'' and ''2', will add them synchronously, and will send the result asynchronously to the customer object, which was passed by reference, i.e. ''customer'' is bound to a far reference. Eventually, the actor that sent the ''add'' message will itself receive a ''result'' message, and when this message is processed by the anonymous consumer object, the result is printed:
+Because of the parameter passing rules described above, the ''add'' method will receive copies of the numbers ''1'' and ''2'', will add them synchronously, and will send the result asynchronously to the customer object, which was passed by reference, i.e. ''customer'' is bound to a far reference. Eventually, the actor that sent the ''add'' message will itself receive a ''result'' message, and when this message is processed by the anonymous consumer object, the result is printed:
 <code>
@@ Line 81: / Line 83: @@
 </code>
-futures
+<note>
+The parameter passing semantics just described lead to a model where the only references that cross actor boundaries are far references. In combination with the message sending semantics described previously, this guarantees that asynchronous messages are the only type of messages that can cross actor boundaries, ensuring that concurrent (and as will be shown later, also distributed) communication is strictly asynchronous. In such a model, deadlocks cannot occur (an actor is never blocked) and race conditions within one single actor can never occur. These properties significantly reduce the complexity of concurrent programs.
+</note>
 === Isolates ===
-isolate stripe, by-copy, scoping rules, no external method defs
+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-[assed 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 //isolated// from their lexical scope. Continuing our previous example, imagine we want our calculator to work with complex numbers, which are typically objects that one would want to pass by copy. We can define complex numbers as isolate objects as follows:
+<code>
+>def complexNumber := isolate: {
+  def re; // assume cartesian coordinates
+  def im;
+  def init(re,im) {
+    self.re := re;
+    self.im := im;
+  };
+  def +(other) {
+    self.new(re+other.re, im+other.im);
+  };
+};
+>><object:15603573[<stripe:Isolate>]>
+</code>
+The ''isolate:'' primitive is actually syntactic sugar for the creation of an object that is automatically striped with the ''/.at.stripes.Isolate'' stripe. Any object that is striped with this stripe is treated as an isolate. If you are a Java programmer, you can best compare this behaviour to having to implement the ''java.io.Serializable'' interface to make a class's instances serializable.
+An isolate differs from a regular object as follows:
+  - it has **no** access to its surrounding lexical scope; this means that an isolate only has access to its local fields and methods. An isolate does have access to the global lexical scope of its actor.
+  - it is parameter-passed by-copy rather than by-reference in inter-actor message sends. The copy of the isolate received by the remote actor can only access that actor's global lexical scope, no longer the global scope of its original host.
+  - external method definitions on isolates are disallowed. The reason for this is that external method definitions implicitly carry a lexical scope (the scope of their definition). Hence, if an isolate with external methods has to be copied, those scopes would have to be copied as well. Following the rule that objects  encapsulating a lexical scope are pass-by-reference, we chose to disallow external methods on isolates.
+Returning to the calculator example, the calculator can now add complex numbers locally and send (a copy of) the resulting complex number back to the customer:
+<code>
+>calculator<-add(
+  complexNumber.new(1,1),
+  complexNumber.new(2,2),
+  object: {
+    def result(sum) {
+      system.println("sum=("+sum.re+","+sum.im+")");
+    };
+  });
+>>nil
+sum=(3,3)
+</code>
+<note>
+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's fields. Therefore, it is good practice to override the ''=='' method on isolates to compare isolates based on their semantic identity, rather than on their object identity. For example, equality for complex numbers should be defined as:
+<code>
+def ==(other) {
+  (re == other.re).and: { im == other.im }
+}
+</code>
+</note>
+It is important to note that an isolate has no access whatsoever to its encompassing scope. The following code results in an exception:
+<code>
+>def x := 1;
+def adder := isolate: {
+  def add(n) { x + n };
+};
+adder.add(3)
+>>Undefined variable access: x
+origin:
+at adder.add(3)
+</code>
+Sometimes it is useful to initialize an isolate with the values of lexically visible variables. In that case, AmbientTalk allows the programmer to specify which lexical variables should be //copied into// the isolate itself, such that the isolate has its own, local copy of the variable. Lexical variables that need to be copied like this are specified as formal parameters to the closure passed to the ''isolate:'' primitive, as follows:
+<code>
+>def x := 1;
+def adder := isolate: { |x|
+  def add(n) { x + n };
+};
+adder.add(3)
+>>4
+</code>
+=== Futures ===
+As you may have noticed previously, asynchronous message sends do not return any value (that is, they return ''nil''). Quite often, the developer is required to work around this lack of return values by means of e.g. explicit customer objects, as shown previously. This, however, leads to less expressive, more difficult to understand code, where the control flow quickly becomes implicit.
+The most well-known language feature to reconcile return values with asynchronous message sends is the notion of a //future//. 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:
+<code>
+def sum := calculator<-add(1,2);
+</code>
+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 //promises// (this is how they are called in the [[http://www.erights.org|E language]] and in Argus). In AmbientTalk, futures are not native to the language. However, because of AmbientTalk's reflective infrastructure, it is possible to build futures on top of the language. The system library shipped with AmbientTalk contains exactly this: a reflective implementation that adds futures to the language kernel. This implementation can be found in the file ''at/lang/futures.at''.
+To enable futures, it suffices to import the futures module and to enable it, as follows:
+<code>
+import /.at.lang.futures;
+enableFutures(true);
+</code>
+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 ''nil''.
 === Actor Mirrors ===