... | ... | @@ -6,14 +6,14 @@ The core computational model of AmbientTalk briefly explained in 10 steps: |
|
|
|
|
|
### 1. Objects
|
|
|
|
|
|
atoverview/1_objects.png
|
|
|
![atoverview/1_objects](atoverview/1_objects.png)
|
|
|
|
|
|
AmbientTalk is an object-based language, it does not feature classes.
|
|
|
Objects can communicate using plain, synchronous, method invocations.
|
|
|
|
|
|
### 2. Actors
|
|
|
|
|
|
atoverview/2_actors.png
|
|
|
![atoverview/2_actors](atoverview/2_actors.png)
|
|
|
|
|
|
All objects are hosted by an actor (the actor is said to *own* the objects). An actor has a queue of pending asynchronous messages (see next step), and a single thread of control with an associated runtime stack. Within an actor there is no concurrency, but different actors can process messages in parallel.
|
|
|
|
... | ... | @@ -21,13 +21,13 @@ For those familiar with the [E language](http://www.erights.org), AmbientTalk ac |
|
|
|
|
|
### 3. Asynchronous messages
|
|
|
|
|
|
atoverview/3_asyncmessages.png
|
|
|
![atoverview/3_asyncmessages](atoverview/3_asyncmessages.png)
|
|
|
|
|
|
Objects can also send each other *asynchronous* messages. These messages end up in the actor’s message queue, to be processed in a later turn (see next step).
|
|
|
|
|
|
### 4. Turns
|
|
|
|
|
|
atoverview/4_turns.png
|
|
|
![atoverview/4_turns](atoverview/4_turns.png)
|
|
|
|
|
|
An actor processes pending asynchronous messages from its queue sequentially. The actor *triggers* the method corresponding to the received message on the receiver object by invoking it. The method is then run to completion. This computational step is called a *turn*. Turns are executed atomically, without interleaving. An actor cannot be suspended or otherwise blocked by any of its objects while processing a message.
|
|
|
|
... | ... | @@ -35,7 +35,7 @@ At the start and end of a turn, the method invocation stack is always empty. At |
|
|
|
|
|
### 5. Futures
|
|
|
|
|
|
atoverview/5_futures.png
|
|
|
![atoverview/5_futures](atoverview/5_futures.png)
|
|
|
|
|
|
Asynchronous messages may immediately return a future. A future is a placeholder for the result of the message. When the result is computed, the future is said to become *resolved*.
|
|
|
|
... | ... | @@ -47,7 +47,7 @@ Futures are like E promises. |
|
|
|
|
|
### 6. Isolation and Partial Failure
|
|
|
|
|
|
atoverview/6_distribution.png
|
|
|
![atoverview/6_distribution](atoverview/6_distribution.png)
|
|
|
|
|
|
A single AmbientTalk VM may host multiple actors. Each of these actors can process messages in parallel. However, actors within the same address space are *isolated*. Objects in one actor cannot directly modify the state of objects in another actor.
|
|
|
|
... | ... | @@ -57,7 +57,7 @@ Actors are the unit of partial failure: individual actors can fail, individual o |
|
|
|
|
|
### 7. Initial Connectivity through Service Discovery
|
|
|
|
|
|
atoverview/7_discovery.png
|
|
|
![atoverview/7_discovery](atoverview/7_discovery.png)
|
|
|
|
|
|
Objects owned by different actors can come to get references to each other using publish/subscribe discovery. AmbientTalk is designed for infrastructure-less, ad hoc networks (e.g. mobile phones connected via !WiFi or Bluetooth). Objects may be exported and discovered by means of mutually known *tags*.
|
|
|
|
... | ... | @@ -65,7 +65,7 @@ Discovery is based on broadcasting (which is natural in wireless networks). Two |
|
|
|
|
|
### 8. Far References
|
|
|
|
|
|
atoverview/8_farrefs.png
|
|
|
![atoverview/8_farrefs](atoverview/8_farrefs.png)
|
|
|
|
|
|
References that span different actors are called *far references*. A far reference denotes an individual object **within** another actor, it is not a reference to the actor as a whole. Far references carry *only* asynchronous method invocations (it is an error to invoke a method synchronously on a far reference). Asynchronous invocations are sent to the actor owning the receiver object, who schedules the invocation in its queue and eventually performs it.
|
|
|
|
... | ... | @@ -75,7 +75,7 @@ Synchronous method invocations on remote objects are prohibit, it is not possibl |
|
|
|
|
|
### 9. Near versus Far Objects
|
|
|
|
|
|
atoverview/9_nearvsfar.png
|
|
|
![atoverview/9_nearvsfar](atoverview/9_nearvsfar.png)
|
|
|
|
|
|
Actors carve the object heap into a globally asynchronous system, and a locally synchronous system. Within an actor, code can perform synchronous, atomic, coordinated changes to multiple objects owned by the same actor. This atomicity is cheap, because there is no concurrency within an actor. However, to exploit it, all objects involved in a "transaction" must be owned by the same actor.
|
|
|
|
... | ... | @@ -87,7 +87,7 @@ In AmbientTalk, the important distinction is whether an object is 'near' or 'far |
|
|
|
|
|
### 10. Delivery Guarantees across Far References
|
|
|
|
|
|
atoverview/10_buffer.png
|
|
|
![atoverview/10_buffer](atoverview/10_buffer.png)
|
|
|
|
|
|
AmbientTalk is designed for use on computer networks with intermittent connectivity (i.e. a high rate of transient disconnections). Therefore, far references do not 'break' upon network failure. Instead, they buffer messages transparently until the connection is restored. Hence, temporary disconnections are masked transparently (although it is possible, and common, for objects to post observers on far references, notifying them when connectivity is lost or restored).
|
|
|
|
... | ... | |