c# barcode generator library open source A Different Approach to Concurrency: Look Ma, No Locks in Font

Create Data Matrix ECC200 in Font A Different Approach to Concurrency: Look Ma, No Locks

The Actor model provides an alternative mechanism for dealing with concurrency and more generally, the listener pattern, event handling, and many of the other things we associate with object-oriented programming.

1. Except if you use Thread.stop(). 137

Actors are threadless, stackless units of execution that process messages (events) serially. Actors were originally developed by Carl Hewitt2 and some other folks in 1973.3 Actors process incoming messages and encapsulate their state. At this point, Actors sound a lot like OOP message sending and encapsulation, and it turns out this is the case. The Actor message-passing semantics grew out of Hewitt s review of Smalltalk. Scheme had an early implementation of Actors.4 Today, the best-known Actor implementation is Erlang, which provides a very powerful distributed Actor mechanism. Smalltalk, Objective-C, Ruby, JavaScript, and Python are unityped or duck-typed languages.5 Instances in each of those languages is of the same type. You can send any message or invoke any method on any instance. The ability for an instance to process a method or message is determined at runtime. Scala, on the other hand, is a statically typed language where the class of every instance is known at compile time and the availability of a method on a given instance can be verified at compile time. Like instances in duck-typed languages, Actors process messages at runtime, and there s no compile-time checking to see whether the Actor can process a particular message. The key differences between Actors and duck-typed instances are that Actors always process messages asynchronously and may not process messages in the order that they were delivered. Messages are delivered to an Actor s mailbox, and the Actor processes the mailbox by removing the first message from the mailbox that the Actor can currently process. If the Actor cannot process any messages currently in the mailbox, the Actor is suspended until the state of the mailbox changes. The Actor will only process one message at a time. Multiple messages can show up in the Actor s mailbox while the Actor is processing a message. Because the Actor does not expose state and can only be modified or queried via messages, and because messages are processed serially, there s no reason to assert locks on internal Actor state. Thus, Actors are lockless at the application level, yet thread-safe.

To send a message to an Actor, you use the ! (bang) method. Thus actor ! msg is the syntax for sending a message to an Actor. Actors are implemented as a library, and there s no specific support for Actors in the Scala compiler. As we wrote our own List class, you could write your own Actor library. Actors are defined in two parts. First, you define the messages that an Actor can receive, and second you define the Actor itself. Actors can receive any message that can be pattern matched in Scala. The following are legal messages, but we haven t defined the Actor s message handling, so we don t know what, if anything, these messages do.

2. 3. 4. 5.

http://carlhewitt.info/ http://en.wikipedia.org/wiki/Actor_model http://www.brics.dk/~hosc/local/HOSC-11-4-pp399-404.pdf The term duck-typed comes from the phrase If it walks like a duck and quacks like a duck, it must be a duck. If an instance can process the walk and quack messages, it must be a duck.

! ! ! !

"Hello" 42 ("Add", 1) List(1,2,3)

I find that except for the most trivial Actor code, I like to use case classes to define messages to an Actor. This allows me to change the parameters that a particular message accepts, and the compiler will flag places in the code where the messages is used. Thus

case class Add(i: Int) a ! Add(1)