Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:tutorial:actors

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
at:tutorial:actors [2007/04/06 20:22] – added tvcutsemat:tutorial:actors [2007/04/07 20:20] – added tvcutsem
Line 36: Line 36:
 ==== Asynchronous Message Sending ==== ==== Asynchronous Message Sending ====
  
-AmbientTalk, like E, lexically distinguishes between synchronous method invocation and asynchronous message sending. The former is expressed as ''o.m()'' while the latter is expressed as ''o<-m()''. Regular object references can carry both kinds of invocations. Synchronous method invocation behaves as in any typical object-oriented language. When an asynchronous message is sent to a local object ("local" meaning "hosted by the same actor"), the message is enqueued in the actor's own message queue and the method invocation will be executed at a later point in time.+AmbientTalk, like E, syntactically distinguishes between synchronous method invocation and asynchronous message sending. The former is expressed as ''o.m()'' while the latter is expressed as ''o<-m()''. Regular object references can carry both kinds of invocations. Synchronous method invocation behaves as in any typical object-oriented language. When an asynchronous message is sent to a local object ("local" meaning "hosted by the same actor"), the message is enqueued in the actor's own message queue and the method invocation will be executed at a later point in time.
  
 Far references, like the reference stored in the variable ''a'' above, only carry asynchronous message sends, and as such totally decouple objects hosted by different actors in time: objects can //never// be blocked waiting for an outstanding remote procedure call, they can only communicate by means of purely //asynchronous// message passing. This is a key property of AmbientTalk's concurrency model, and it is a crucial property in the context of [[distribution|distributed programming]]. Far references, like the reference stored in the variable ''a'' above, only carry asynchronous message sends, and as such totally decouple objects hosted by different actors in time: objects can //never// be blocked waiting for an outstanding remote procedure call, they can only communicate by means of purely //asynchronous// message passing. This is a key property of AmbientTalk's concurrency model, and it is a crucial property in the context of [[distribution|distributed programming]].
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: 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 and closures are always passed **by reference**+  - Objects and closures are always passed **by far 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**
  
Line 89: 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-[assed 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 //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: 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:
Line 169: Line 169:
 === The Concept === === The Concept ===
  
-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.+The most well-known language feature to reconcile return values with asynchronous message sends is the notion of a [[Wp>Future_(programming)|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: Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows:
Line 199: Line 199:
  
 <note>Should add example here</note> <note>Should add example here</note>
 +
 +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.
 +
 +AmbientTalk only allows one method to be synchronously invoked on a future, the ''=='' method. A word of warning though: equality on futures is defined as pointer equality, so a future will only be equal to itself. It does not compare the parameter object with its actual value, if it would be resolved.
  
 === 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:
  
 +<code>
 +def sum := calculator<-add(1,2);
 +system.println(sum);
 +>> <unresolved future>
 +</code>
 +
 +AmbientTalk prints the future to the screen. At a later point in time, printing the future again may result in the following:
 +
 +<code>
 +>system.println(sum);
 +>> <resolved future:3>
 +</code>
 +
 +This time, the future was printed when the return value was computed. But what if we simply want to inform the user of the actual value of ''sum''? In such cases, you need to register an observer with the future, which will be asynchronously notified when the actual value of the future has been computed.
 +
 +In AmbientTalk, this observer takes the form of a closure which will be applied asynchronously, taking as its only argument the actual value of the future. Registering the observer can be easily done by means of the ''when:becomes:'' function, exported by the futures module:
 +
 +<code>
 +def sumFuture := calculator<-add(1,2);
 +when: sumFuture becomes: { |sum|
 +  system.println("The sum is " + sum);
 +};
 +</code>
 +
 +The first argument to ''when:becomes:'' is the future to observe. The second argument is a closure that takes the actual return value as a formal parameter. If there is a possibility that the asynchronously invoked method can raise an exception, this exception can be caught asynchronously by means of the ''when:becomes:catch:'' variant:
 +
 +<code>
 +def sumFuture := calculator<-add(1,2);
 +when: sumFuture becomes: { |sum|
 +  system.println("The sum is " + sum);
 +} catch: { |exc|
 +  system.println("Exception: " + exc.message);
 +};
 +</code>
 +
 +Or, you can specify a stripe to only catch specific exceptions:
 +
 +<code>
 +def divFuture := calculator<-divide(a,b);
 +when: divFuture becomes: { |div|
 +  system.println("The division is " + div);
 +} catch: DivisionByZero using: { |exc|
 +  system.println("Cannot divide "+a+" by zero!");
 +};
 +</code>
 +
 +The ''when:*'' functions are a very easy mechanism to synchronise on the value of a future without actually making an actor block: remember that all the ''when:becomes:'' function does is register the closure with the future. After that, the actor simply continues processing the statement following ''when:becomes:''. Also, even if the future is already resolved at the time the closure observer is registered, the closure is guaranteed to be applied asynchronously. This guarantees that the code following a ''when:becomes:'' block is executed before the registered closure itself:
 +
 +<code>
 +when: sumFuture becomes: { |sum|
 +  system.println("... and here later.");
 +};
 +system.print("Always here first");
 +>>Always here first... and here later.
 +</code>
 +
 +Finally, it is useful to know that ''when:becomes:'' itself returns a future, who will be resolved with the value of applying the observer closure:
 +
 +<code>
 +def fut := when: calculator<-add(1,2) becomes: { |sum|
 +  calculator<-add(sum,3)
 +};
 +</code>
 +
 +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 ===
 +
 +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.
 +
 +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:
 +
 +<code>
 +o<-m()@OneWayMessage
 +</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:
 +
 +<code>
 +o<-m()@FutureMessage
 +</code>
 +
 +Finally, it is possible to first invoke ''enableFutures(false)'' and later enable it by default anyway by invoking ''enableFutures(true)''. However, once futures have been enabled by default, they can no longer be "turned off" by default. The reason for this is that if two separate files load the futures module and one enables futures by default and the other does not, then the net result is that they will be enabled by default, which will make both applications work correctly. If futures could be disabled, this can cause one object to unexpectedly make other objects crash because they depend on 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:
 +
 +<code>
 +def [future, resolver] := makeFuture();
 +consumer<-give(future);
 +def val := /* calculate useful value */
 +resolver.resolve(val);
 +</code>
 +
 +The ''makeFuture'' function exported by the futures module returns two values: a new, unresolved future, and an object called a //resolver// that can be used to resolve the future. As shown in the example, the future can be passed around as a regular object, and code can synchronise on the future by registering an observer on it, as shown previously. The resolver can be handed out separately to other parts of the program, which calculate the value for the future. This enables objects to "synchronise" on the future without being restricted to return values.
 +
 +The resolver also defines a ''ruin(e)'' method which can be used to explicitly ruin a future, causing any attached ''when:becomes:catch:'' blocks to trigger their ''catch:'' clause.
  
 ==== Actor Mirrors ==== ==== Actor Mirrors ====
  
-explain: mirror factory, message creation, message sending, install+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 ''send'' and ''receive'' that can be overridden to customise e.g. message sending on a per-object basis. 
 + 
 +Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, the programmer could override the way messages are sent by any object from within an actor. The mirror on an actor that reifies these operations is bound to the ''actor'' variable, defined at top-level. Evaluating ''actor'' returns the mirror on the current actor. It defines operations such as ''createMessage'' and ''send'' which can be explicitly invoked, or even overridden by the programmer. 
 + 
 +Overriding the actor's metaobject protocol can be done by //installing// a new protocol object. This is done by invoking the ''install:'' method on ''actor''. The following code installs a new MOP that logs any messages sent by any object in the current actor: 
 + 
 +<code> 
 +def oldmirror := actor.install: (extend: actor with: { 
 +  def send(msg) { 
 +    log(msg); 
 +    super^send(msg); 
 +  }; 
 +}); 
 +</code> 
 + 
 +Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent's behaviour simply by means of a super-send. Note also that the ''install:'' primitive returns the previously installed mirror. This is useful for when an actor mirror should only temporarily be installed. The old mirror can later be re-installed. 
 + 
 +For a good use case of actor mirrors, see the ''at/lang/futures.at'' file in the system library. This file implements future-type message passing. It uses a custom actor mirror that overrides ''createMessage'' -- which is invoked whenever an asynchronous message is created -- to attach a future to the message. 
 + 
 +Other methods that can be overridden are ''require'' and ''provide'', which reify the export and discovery of objects, and ''createMirror'', which is invoked by the ''reflect:'' primitive. By overriding this //factory method//, it becomes possible to easily customize the behaviour of mirrors defined on local objects.
  
 ==== Nesting Actors ==== ==== Nesting Actors ====
  
-lexical scoping rules for nested actors+In AmbientTalk, objects can be nested inside other objects and functions can be defined in other functions. It makes sense to ask whether actors can also be nested. The answer is that yes, actors too can be nested. However, this is not as straightforward as it seems. Consider the following example: 
 + 
 +<code> 
 +def outer := actor: { 
 +  def x := 1; 
 +  def get() { x }; 
 +  def set(v) { x := v }; 
 + 
 +  def inner := actor: { 
 +    def get() { x }; 
 +    def set(v) { x := v }; 
 +  }; 
 +}; 
 +</code> 
 + 
 +If both the ''outer'' and ''inner'' actors lexically see ''x'', they could modify it concurrently, reintroducing race conditions on the internal state of an actor. Therefore, when defining an actor using a block of code, we disallow access to the enclosing lexical scope by the new actor. It is as if it was defined at top-level. Hence, actors behave similarly to [[#isolates|isolates]] in this respect. The above example is incorrect in that ''inner'' will not be able to read or modify ''x''. 
 + 
 +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: 
 + 
 +<code> 
 +def outer := actor: { 
 +  def x := 1; 
 +  def get() { x }; 
 +  def set(v) { x := v }; 
 + 
 +  def inner := actor: { |x| 
 +    def get() { x }; 
 +    def set(v) { x := v }; 
 +  }; 
 +}; 
 +</code> 
 + 
 +Hence, it still makes sense to nest actors, but each actor will operate on its own local copy of the variable. Furthermore, the value bound to the copied variable is parameter-passed according to inter-actor parameter passing rules, so if ''x'' would be bound to an object, then ''outer'' would have a normal reference to the object, while ''inner'' would receive a far reference to the object.
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag