User Tools

Site Tools


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:40] – added tvcutsemat:tutorial:actors [2007/04/07 17:18] – *changed 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 253: Line 253:
 }; };
 </code> </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 ensures that the code following a ''when:becomes:'' block is guaranteed to be 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>
 +
 +=== Futures and Striped Messages ===
 +
 +Explain:
 +''o<-m()@FutureMessage''
 +''o<-m()@OneWayMessage''
 +
 +=== Conditional Synchronisation with Futures ===
 +
 +explain: explicit futures using ''makeFuture''
  
 ==== Actor Mirrors ==== ==== Actor Mirrors ====
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag