2.7 Actor life cycle

Because of their readiness to process incoming messages, actors can be imagined as "live objects," or objects with a life cycle. Unlike the lives of movie actors, the life of an actor object is rather boring: Once an actor is created, it typically starts processing incoming messages. Once an actor has exceeded its useful life, it can be stopped and destroyed, either of its own accord, or as a result of some "poison pill" message.

Creating and starting an actor are separate, although closely related, tasks. In Scala, actors are plain old Scala objects, and can therefore be created via their constructors. An actor starts processing incoming messages after it has been started, which is similar to starting a Java thread.

In practice, it is useful for actors to be able to monitor each others' life-cycle events. In the fork-join example, for instance, a child actor may decide to terminate upon sending its response to the parent, in order to free up memory. At that point, it could send a message to its parent actor indicating its exit. In Scala Actors, life-cycle monitoring is supported through actor links. Actor linking is explained in detail in Section ???.

Footnotes for Chapter 2:

[1] Note that even if global state is not accessed concurrently, care has to be taken to avoid thread visibility issues. For example, on the JVM updating the field of a shared object may not be visible to subsequent threads reading the same field. Only the use of synchronizing operations, such as locking via synchronized methods or accessing volatile fields ensures that updates "happen before" subsequent reads, and therefore become visible. You can find an excellent discussion of thread visibility on the JVM in Goet06a.

[2] One of the reasons why scalability is hard to achieve using locks (or Java-style synchronization) is the fact that coarse-grained locking increases the amount of code that is executed sequentially. Moreover, accessing a small number of locks (or, in the extreme case, a single global lock) from several threads may increase the cost of synchronization significantly.

[3] Agha, "Concurrent Object-Oriented Programming" Agha90

[4] Kay, an email on messaging in Smalltalk/Squeak. Kay98

[5] Hewitt and Baker, "Laws for Communicating Parallel Processes" hewitt:laws

[6] AJAX was originally coined as an acronym for Asynchronous JavaScript and XML.

[7] In Scala actors, the guarantees of message delivery are a bit stronger than the full indeterminacy of the pure actor programming model. If an actor sends several messages to the same receiver, those messages arrive in the receiving actor's in the order in which they have been sent.