at:tutorial:actors
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
at:tutorial:actors [2007/04/01 13:05] – tvcutsem | at:tutorial:actors [2007/04/06 20:22] – added tvcutsem | ||
---|---|---|---|
Line 5: | Line 5: | ||
Concurrency is an integral part of the AmbientTalk programming language. Rather than relying on [[wp> | Concurrency is an integral part of the AmbientTalk programming language. Rather than relying on [[wp> | ||
- | === Threads vs Actors === | + | ==== Threads vs Actors |
In traditional programming languages, the control flow of a concurrent program is divided over a number of threads. Each thread operates concurrently and control can switch from one thread to another non-deterministically. If two threads have access to the same data (objects), they might cause erroneous behaviour (so-called //race conditions// | In traditional programming languages, the control flow of a concurrent program is divided over a number of threads. Each thread operates concurrently and control can switch from one thread to another non-deterministically. If two threads have access to the same data (objects), they might cause erroneous behaviour (so-called //race conditions// | ||
Line 15: | Line 15: | ||
Generally speaking, an active object is an object that encapsulates its own thread of control. An active object also has a message queue or mailbox from which it processes incoming messages. Each message is processed sequentially. An active object responds to an incoming message by invoking the method corresponding to the message. The method is executed by the active object' | Generally speaking, an active object is an object that encapsulates its own thread of control. An active object also has a message queue or mailbox from which it processes incoming messages. Each message is processed sequentially. An active object responds to an incoming message by invoking the method corresponding to the message. The method is executed by the active object' | ||
- | === Actors and Far References === | + | ==== Actors and Far References |
In AmbientTalk, | In AmbientTalk, | ||
Line 34: | Line 34: | ||
So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below. | So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below. | ||
- | === Asynchronous Message Sending === | + | ==== Asynchronous Message Sending |
AmbientTalk, | AmbientTalk, | ||
Line 87: | Line 87: | ||
</ | </ | ||
- | === 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-[assed as well. | ||
Line 163: | Line 163: | ||
</ | </ | ||
- | === Futures === | + | ==== Futures |
- | futures language construct | + | As you may have noticed previously, asynchronous message sends do not return any value (that is, they return '' |
- | === Actor Mirrors === | + | === 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. | ||
+ | |||
+ | Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows: | ||
+ | |||
+ | < | ||
+ | def sum := calculator< | ||
+ | </ | ||
+ | |||
+ | === Enabling futures === | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | To enable futures, it suffices to import the futures module and to enable it, as follows: | ||
+ | |||
+ | < | ||
+ | import / | ||
+ | enableFutures(true); | ||
+ | </ | ||
+ | |||
+ | 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 '' | ||
+ | |||
+ | === Working with Unresolved Futures === | ||
+ | |||
+ | We have yet to describe what objects can do with futures that are // | ||
+ | |||
+ | Blocking a thread on a future can be a major source of deadlocks, like any form of blocking, of course. In the actor paradigm where communication between actors should remain strictly asynchronous, | ||
+ | |||
+ | The solution proposed in the [[http:// | ||
+ | |||
+ | < | ||
+ | |||
+ | === Working with Resolved Futures === | ||
+ | |||
+ | |||
+ | |||
+ | ==== Actor Mirrors | ||
explain: mirror factory, message creation, message sending, install | explain: mirror factory, message creation, message sending, install | ||
- | === Nesting Actors === | + | ==== Nesting Actors |
lexical scoping rules for nested actors | lexical scoping rules for nested actors |
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag