This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
at:tutorial:actors [2007/04/01 13:04] tvcutsem added |
at:tutorial:actors [2020/02/05 21:26] elisag |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | < | ||
- | ===== Concurrent Programming with Actors ===== | ||
- | |||
- | Concurrency is an integral part of the AmbientTalk programming language. Rather than relying on [[wp> | ||
- | |||
- | === 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// | ||
- | |||
- | The advantages of the thread-based model are that the model itself is easy to understand, it is efficiently implementable and it can be used to create very fine-grained synchronization (e.g. [[wp> | ||
- | |||
- | The original [[wp> | ||
- | |||
- | 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 === | ||
- | |||
- | In AmbientTalk, | ||
- | |||
- | When an actor is created, it hosts a single object which is said to be the actor' | ||
- | |||
- | < | ||
- | >def a := actor: { | ||
- | def sayHello() { | ||
- | system.println(" | ||
- | }; | ||
- | }; | ||
- | >>< | ||
- | </ | ||
- | |||
- | As you can see, actors are created similar to objects. The '' | ||
- | |||
- | 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 === | ||
- | |||
- | AmbientTalk, | ||
- | |||
- | Far references, like the reference stored in the variable '' | ||
- | |||
- | Hence, given the example above, the method '' | ||
- | |||
- | < | ||
- | > | ||
- | >>nil | ||
- | </ | ||
- | |||
- | The above code is simple enough to understand: the '' | ||
- | |||
- | 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** | ||
- | - Native data types like numbers, text, tables, ... are always passed **by copy** | ||
- | |||
- | Generally speaking, any object that encapsulates a lexical scope is passed by reference, because passing such an object by copy would entail passing the entire lexical scope by copy - a costly operation. Objects without a lexical scope, such as methods, can be copied without having to recursively copy any scope. | ||
- | |||
- | When an object is passed by reference, we mean that the formal parameter of a method will be bound to a far reference to the original object. When it is passed by copy, the formal parameter will be bound to a local copy of the object. For example, consider the following '' | ||
- | |||
- | < | ||
- | >def calculator := actor: { | ||
- | def add(x, | ||
- | customer< | ||
- | }; | ||
- | }; | ||
- | >>< | ||
- | </ | ||
- | |||
- | The '' | ||
- | |||
- | < | ||
- | > | ||
- | def result(sum) { | ||
- | system.println(" | ||
- | }; | ||
- | }); | ||
- | >>nil | ||
- | </ | ||
- | |||
- | Because of the parameter passing rules described above, the '' | ||
- | |||
- | < | ||
- | sum = 3 | ||
- | </ | ||
- | |||
- | < | ||
- | The parameter passing semantics just described lead to a model where the only references that cross actor boundaries are far references. In combination with the message sending semantics described previously, this guarantees that asynchronous messages are the only type of messages that can cross actor boundaries, ensuring that concurrent (and as will be shown later, also distributed) communication is strictly asynchronous. In such a model, deadlocks cannot occur (an actor is never blocked) and race conditions within one single actor can never occur. These properties significantly reduce the complexity of concurrent programs. | ||
- | </ | ||
- | |||
- | === 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. | ||
- | |||
- | 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 // | ||
- | |||
- | < | ||
- | >def complexNumber := isolate: { | ||
- | def re; // assume cartesian coordinates | ||
- | def im; | ||
- | def init(re,im) { | ||
- | self.re := re; | ||
- | self.im := im; | ||
- | }; | ||
- | def +(other) { | ||
- | self.new(re+other.re, | ||
- | }; | ||
- | }; | ||
- | >>< | ||
- | </ | ||
- | |||
- | The '' | ||
- | |||
- | An isolate differs from a regular object as follows: | ||
- | - it has **no** access to its surrounding lexical scope; this means that an isolate only has access to its local fields and methods. An isolate does have access to the global lexical scope of its actor. | ||
- | - it is parameter-passed by-copy rather than by-reference in inter-actor message sends. The copy of the isolate received by the remote actor can only access that actor' | ||
- | - external method definitions on isolates are disallowed. The reason for this is that external method definitions implicitly carry a lexical scope (the scope of their definition). Hence, if an isolate with external methods has to be copied, those scopes would have to be copied as well. Following the rule that objects | ||
- | |||
- | Returning to the calculator example, the calculator can now add complex numbers locally and send (a copy of) the resulting complex number back to the customer: | ||
- | |||
- | > | ||
- | complexNumber.new(1, | ||
- | complexNumber.new(2, | ||
- | object: { | ||
- | def result(sum) { | ||
- | system.println(" | ||
- | }; | ||
- | }); | ||
- | >>nil | ||
- | sum=(3,3) | ||
- | </ | ||
- | |||
- | < | ||
- | A word of warning: isolates are objects that are copied freely between actors. As a result, they should be objects whose actual object identity is of little importance. Usually, the identity of by-copy objects is determined by the value of some of the object' | ||
- | < | ||
- | def ==(other) { | ||
- | (re == other.re).and: | ||
- | } | ||
- | </ | ||
- | </ | ||
- | |||
- | It is important to note that an isolate has no access whatsoever to its encompassing scope. The following code results in an exception: | ||
- | |||
- | < | ||
- | >def x := 1; | ||
- | def adder := isolate: { | ||
- | def add(n) { x + n }; | ||
- | }; | ||
- | adder.add(3) | ||
- | >> | ||
- | origin: | ||
- | at adder.add(3) | ||
- | </ | ||
- | |||
- | Sometimes it is useful to initialize an isolate with the values of lexically visible variables. In that case, AmbientTalk allows the programmer to specify which lexical variables should be //copied into// the isolate itself, such that the isolate has its own, local copy of the variable. Lexical variables that need to be copied like this are specified as formal parameters to the closure passed to the '' | ||
- | |||
- | < | ||
- | >def x := 1; | ||
- | def adder := isolate: { |x| | ||
- | def add(n) { x + n }; | ||
- | }; | ||
- | adder.add(3) | ||
- | >>4 | ||
- | </ | ||
- | |||
- | === Futures === | ||
- | |||
- | futures language construct | ||
- | |||
- | === Actor Mirrors === | ||
- | |||
- | explain: mirror factory, message creation, message sending, install | ||
- | |||
- | === Nesting Actors === | ||
- | |||
- | lexical scoping rules for nested actors |