|
|
# The core computational model of AmbientTalk briefly explained in 10 steps.
|
|
|
|
|
|
## The Essence of AmbientTalk in 10 Steps
|
|
|
|
|
|
The core computational model of AmbientTalk briefly explained in 10 steps:
|
|
|
|
|
|
### 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
|
|
|
|
|
|
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.
|
|
|
|
|
|
For those familiar with the [E language](http://www.erights.org), AmbientTalk actors are equivalent to E vats.
|
|
|
|
|
|
### 3. Asynchronous messages
|
|
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
|
|
At the start and end of a turn, the method invocation stack is always empty. At any given time, execution proceeds from stack top-to-bottom, then from queue left-to-right.
|
|
|
|
|
|
### 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*.
|
|
|
|
|
|
AmbientTalk futures are non-blocking: the value of a future may be awaited, not by blocking as is typical of futures, but by registering a closure as an observer on the future, to be notified in a later turn. Objects cannot block on an unresolved future; they cannot suspend their actor in the middle of a turn.
|
|
|
|
|
|
Objects may send asynchronous messages to futures as if they already denoted their resolved value, even if the future is not yet resolved. These messages are buffered by the future and will be forwarded as soon as the future becomes resolved. This is a form of *data flow* synchronization.
|
|
|
|
|
|
Futures are like E promises.
|
|
|
|
|
|
### 6. Isolation and Partial Failure
|
|
|
|
|
|
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.
|
|
|
|
|
|
Actors executing on different VMs connected via a computer network may come to discover one another (see next step). As far as an actor is concerned, it does not matter whether its peer actors reside in the same address space or not (the model does not distinguish between a peer actor residing on the same VM or on a remote VM).
|
|
|
|
|
|
Actors are the unit of partial failure: individual actors can fail, individual objects cannot.
|
|
|
|
|
|
### 7. Initial Connectivity through Service 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*.
|
|
|
|
|
|
Discovery is based on broadcasting (which is natural in wireless networks). Two AmbientTalk VMs that discover each other establish a peer-to-peer connection and exchange their outstanding subscriptions to find a match.
|
|
|
|
|
|
### 8. Far References
|
|
|
|
|
|
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.
|
|
|
|
|
|
Arguments of inter-actor asynchronous messages are always serialized. By default, objects are passed by-far-reference, but it is possible to create and transmit pass-by-copy objects as well. Pass-by-copy objects may contain both state and behavior (methods).
|
|
|
|
|
|
Synchronous method invocations on remote objects are prohibit, it is not possible to perform a synchronous RPC. The exclusive use of asynchronous message sends ensures that an actor (and all of its objects) is always responsive: it is free to process other messages while the message is delivered. This strategy also hides the large latency associated with communicating across volatile, wireless networks.
|
|
|
|
|
|
### 9. Near versus Far Objects
|
|
|
|
|
|
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.
|
|
|
|
|
|
Actors are globally asynchronous. In AmbientTalk, conventional deadlock cannot occur. It is possible that two or more actors fail to make progress (so-called "lost progress" bugs), but unlike deadlocks, these situations are often *deterministic* and thus much easier to reproduce and resolve.
|
|
|
|
|
|
In AmbientTalk, conventional memory races cannot occur. However, the non-determinism inherent to concurrent and distributed programming is reflected in the arrival order of messages: this arrival order is non-deterministic, and programmers have to take this non-determinism into account.
|
|
|
|
|
|
In AmbientTalk, the important distinction is whether an object is 'near' or 'far'. Far objects may either reside on the same machine, or may be distributed. Most of the time, programmers can make abstraction of this. Objects can always reliably communicate with near objects, and should always plan for failure handling when communicating with far objects.
|
|
|
|
|
|
### 10. Delivery Guarantees across Far References
|
|
|
|
|
|
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).
|
|
|
|
|
|
Of course, the connection may never be restored. To cope with this, it is possible to post either a timeout on an individual message, or a timeout on a far reference as a whole (the latter are known as *leased* far references). When an asynchronous message expires, its associated future is *ruined* with an exception.
|
|
|
|
|
|
The failure handling strategy of buffering messages during disconnections is made possible because AmbientTalk forces all remote message sends to be asynchronous. This decouples sender and receiver objects and makes them more resilient to failures.
|
|
|
|
|
|
AmbientTalk provides FIFO message ordering guarantees across far references.
|
|
|
|
|
|
### Further Reading
|
|
|
|
|
|
The above 10 steps only covered the core computational model of AmbientTalk. The [tutorial](http://soft.vub.ac.be/amop/at/tutorial/tutorial) explains the language in more detail.
|
|
|
|
|
|
AmbientTalk is mainly used as a research language for experimenting with new language features for ad hoc networks. Examples of such features include:
|
|
|
- [Ambient references](http://soft.vub.ac.be/amop/research/ambientrefs) supporting different anycast and multicast messaging strategies
|
|
|
- Reactive programming
|
|
|
- [Leasing strategies](http://soft.vub.ac.be/Publications/2009/vub-prog-tr-09-06.pdf)
|
|
|
- [Representing RFID tags as objects](http://soft.vub.ac.be/~alombide/AmbientTalkRFID_DAIS2010.pdf)
|
|
|
- ... |