Odersky M. Programming in Scala
Подождите немного. Документ загружается.
Section 30.2 Chapter 30 · Actors and Concurrency 611
Nothing happens in this case, because SillyActor is too busy acting to pro-
cess its messages, and so the "hi there" message sits in its mailbox unread.
Listing 30.2 shows a new, more sociable, actor that waits for a message in its
mailbox and prints out whatever it receives. It receives a message by calling
receive, passing in a partial function.
1
val echoActor = actor {
while (true) {
receive {
case msg =>
println("received message: "+ msg)
}
}
}
Listing 30.2 · An actor that calls receive.
When an actor sends a message, it does not block, and when an actor re-
ceives a message, it is not interrupted. The sent message waits in the receiv-
ing actor’s mailbox until the actor calls receive. You can see this behavior
illustrated here:
scala> echoActor ! "hi there"
received message: hi there
scala> echoActor ! 15
scala> received message: 15
As discussed in Section 15.7, a partial function (an instance of trait
PartialFunction) is not a full function—i.e., it might not be defined over
all input values. In addition to an apply method that takes one argument,
a partial function offers an isDefinedAt method, which also takes one ar-
gument. The isDefinedAt method will return true if the partial function
can “handle” the passed value. Such values are safe to pass to apply. If you
pass a value to apply for which isDefinedAt would return false, however,
apply will throw an exception.
1
As described in Section 15.7, a partial function literal is expressed as a series of match
alternatives or “cases.” It looks like a match expression without the match keyword.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.3 Chapter 30 · Actors and Concurrency 612
An actor will only process messages matching one of the cases in the par-
tial function passed to receive. For each message in the mailbox, receive
will first invoke isDefinedAt on the passed partial function to determine
whether it has a case that will match and handle the message. The receive
method will choose the first message in the mailbox for which isDefinedAt
returns true, and pass that message to the partial function’s apply method.
The partial function’s apply method will handle the message. For exam-
ple, echoActor’s apply method will print "received message: " followed
by the message object’s toString result. If the mailbox contains no mes-
sage for which isDefinedAt returns true, the actor on which recieve was
invoked will block until a matching message arrives.
For example, here is an actor that handles only messages of type Int:
scala> val intActor = actor {
receive {
case x: Int => // I only want Ints
println("Got an Int: "+ x)
}
}
intActor: scala.actors.Actor =
scala.actors.Actor$$anon$1@34ba6b
If you send a String or Double, for example, the intActor will silently
ignore the message:
scala> intActor ! "hello"
scala> intActor ! Math.Pi
But if you pass an Int, you’ll get a response printed out:
scala> intActor ! 12
Got an Int: 12
30.3 Treating native threads as actors
The actor subsystem manages one or more native threads for its own use. So
long as you work with an explicit actor that you define, you do not need to
think much about how they map to threads.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.4 Chapter 30 · Actors and Concurrency 613
The other direction is also supported by the subsystem: every native
thread is also usable as an actor. However, you cannot use Thread.current
directly, because it does not have the necessary methods. Instead, you should
use Actor.self if you want to view the current thread as an actor.
This facility is especially useful for debugging actors from the interactive
shell. Here’s an example:
scala> import scala.actors.Actor._
import scala.actors.Actor._
scala> self ! "hello"
scala> self.receive { case x => x }
res6: Any = hello
The receive method returns the value computed by the partial function
passed to it. In this case, the partial function returns the message itself, and
so the received message ends up being printed out by the interpreter shell.
If you use this technique, it is better to use a variant of receive called
receiveWithin. You can then specify a timeout in milliseconds. If you use
receive in the interpreter shell, then the receive will block the shell until
a message arrives. In the case of self.receive, this could mean waiting
forever! Instead, use receiveWithin with some timeout value:
scala> self.receiveWithin(1000) { case x => x } // wait a sec!
res7: Any = TIMEOUT
30.4 Better performance through thread reuse
Actors are implemented on top of normal Java threads. As described so far,
in fact, every actor must be given its own thread, so that all the act methods
get their turn.
Unfortunately, despite their light-sounding name, threads are not all that
cheap in Java. Threads consume enough memory that typical Java virtual
machines, which can host millions of objects, can have only thousands of
threads. Worse, switching threads often takes hundreds if not thousands of
processor cycles. If you want your program be as efficient as possible, then
it is important to be sparing with thread creation and switching.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.4 Chapter 30 · Actors and Concurrency 614
To help you conserve threads, Scala provides an alternative to the usual
receive method called react. Like receive, react takes a partial func-
tion. Unlike receive, however, react does not return after it finds and
processes a message. Its result type is Nothing. It evaluates the message
handler and that’s it.
2
Because the react method does not need to return, the implementation
does not need to preserve the call stack of the current thread. Instead, the
library can reuse the current thread for the next actor that wakes up. This
approach is so effective that if every actor in a program uses react instead
of receive, only a single thread is necessary in principle to host all of the
program’s actors (to be sure, if your computer has several processor cores,
the actors subsystem will use enough threads to utilize all cores when it can).
In practice, programs will need at least a few receive’s, but
you should try to use react whenever possible so as to
conserve threads.
Because react does not return, the message handler you pass it must
now both process that message and arrange to do all of the actor’s remaining
work. A common way to do this is to have a top-level work method—such
as act itself—that the message handler calls when it finishes. Listing 30.3
shows an example that uses this approach.
The actor shown in Listing 30.3 waits for strings that are host names, and
if there is one, returns an IP address for that host name. Here’s an example:
scala> NameResolver.start()
res0: scala.actors.Actor = NameResolver$@90d6c5
scala> NameResolver ! ("www.scala-lang.org", self)
scala> self.receiveWithin(0) { case x => x }
res2: Any = Some(www.scala-lang.org/128.178.154.102)
scala> NameResolver ! ("wwwwww.scala-lang.org", self)
scala> self.receiveWithin(0) { case x => x }
res4: Any = None
2
Behind the scenes, react will throw an exception after its done.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.4 Chapter 30 · Actors and Concurrency 615
object NameResolver extends Actor {
import java.net.{InetAddress, UnknownHostException}
def act() {
react {
case (name: String, actor: Actor) =>
actor ! getIp(name)
act()
case "EXIT" =>
println("Name resolver exiting.")
// quit
case msg =>
println("Unhandled message: "+ msg)
act()
}
}
def getIp(name: String): Option[InetAddress] = {
try {
Some(InetAddress.getByName(name))
} catch {
case _:UnknownHostException => None
}
}
}
Listing 30.3 · An actor that calls react.
Writing an actor to use react instead of receive is challenging, but pays
off in performance. Because react does not return, the calling actor’s call
stack can be discarded, freeing up the thread’s resources for a different actor.
At the extreme, if all of the actors of a program use react, then they can be
implemented on a single thread.
This coding pattern is so common with event-based actors, there is spe-
cial support in the library for it. The Actor.loop function executes a block
of code repeatedly, even if the code calls react. NameResolver’s act
method can be rewritten to use loop as shown in Listing 30.4. The one
difference in behavior between this act method and that of Listing 30.3 is
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.5 Chapter 30 · Actors and Concurrency 616
that this one does not handle "EXIT" by quitting. Instead, this actor will loop
and react to messages forever.
def act() {
loop {
react {
case (name: String, actor: Actor) =>
actor ! getIp(name)
case msg =>
println("Unhandled message: " + msg)
}
}
}
Listing 30.4 · An actor’s act method that uses loop.
30.5 Good actors style
At this point you have seen everything you need to write your own actors.
Simply using these methods takes you only so far, however. The point of
them is that they support an actors style of concurrent programming. To
the extent you can write in this style, your code will be easier to debug and
will have fewer deadlocks and race conditions. This section provides some
guidelines for programming in an actors style.
Actors should not block
A well written actor does not block while processing a message. The prob-
lem is that while the actor blocks, some other actor might make a request on
it that it could handle. If the actor is blocked on the first request, it will not
even notice the second request. In the worst case, a deadlock can even result,
with multiple actors blocked as they each wait for some other blocked actor
to respond.
Instead of blocking, the actor should arrange for some message to arrive
designating that action is ready to be taken. Often this rearrangement will re-
quire the help of other actors. For example, instead of calling Thread.sleep
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.5 Chapter 30 · Actors and Concurrency 617
How react works
A return type of Nothing indicates a function will never return nor-
mally, but instead will always complete abruptly with an exception. And
indeed, this is true of react. The actual implementation of react is
not as simple as the following description, and subject to change, but
conceptually you can think of react as working like this:
When you call start on an actor, the start method will in some way
arrange things such that some thread will eventually call act on that
actor. If that act method invokes react, the react method will look in
the actor’s mailbox for a message the passed partial function can handle.
(It does this the same way as receive, by passing candidate messages
to the partial function’s isDefinedAt method.) If it finds a message
that can be handled, react will schedule the handling of that message
for later execution and throw an exception. If it doesn’t find one, it will
place the actor in “cold storage,” to be resurrected if and when it gets
more messages in its mailbox, and throw an exception. In either case,
react will complete abruptly with this exception, and so will act. The
thread that invoked act will catch the exception, forget about the actor,
and move on to other duties.
This is why if you want react to handle more than the first message,
you’ll need to call act again from inside your partial function, or use
some other means to get react invoked again.
directly and blocking the current actor, you could create a helper actor that
sleeps and then sends a message back when enough time has elapsed:
actor {
Thread.sleep(time)
mainActor ! "WAKEUP"
}
This helper actor does indeed block, but since it will never receive a mes-
sage, it is OK in this case. The main actor remains available to answer new
requests. The emoteLater method, shown in Listing 30.5, demonstrates the
use of this idiom. It creates a new actor that will do the sleep so that the
main actor does not block. To ensure that it sends the "Emote" message to
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.5 Chapter 30 · Actors and Concurrency 618
val sillyActor2 = actor {
def emoteLater() {
val mainActor = self
actor {
Thread.sleep(1000)
mainActor ! "Emote"
}
}
var emoted = 0
emoteLater()
loop {
react {
case "Emote" =>
println("I'm acting!")
emoted += 1
if (emoted < 5)
emoteLater()
case msg =>
println("Received: "+ msg)
}
}
}
Listing 30.5 · An actor that uses a helper actor to avoid blocking itself.
the correct actor, it is careful to evaluate self in the scope of the main actor
instead of the scope of the helper actor.
Because this actor does not block in sleep—its helper actor does—it can
continue to do other work while waiting for its next time to emote. Unlike
the earlier silly actor, this one will continue to print out messages while it
waits for its next input:
scala> sillyActor2 ! "hi there"
scala> Received: hi there
I'm acting!
I'm acting!
I'm acting!
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.5 Chapter 30 · Actors and Concurrency 619
Communicate with actors only via messages
The key way the actors model addresses the difficulties of the shared data and
locks model is by providing a safe space—the actor’s act method—where
you can think sequentially. Put another way, actors allow you to write a
multi-threaded program as a bunch of independent single-threaded programs
that communicate with each other via asynchronous messaging. This sim-
plification works, however, only so long as messages are the only way you
let your actors communicate.
3
For example, a GoodActor could include a reference to itself in a mes-
sage to a BadActor, to identify itself as the source of that message. If
BadActor invokes some arbitrary method on GoodActor instead of sending
it a message with ‘!’, however, problems may ensue. The invoked method
might read private instance data in GoodActor, which may have been writ-
ten by a different thread. As a result, you would need to ensure that both the
BadActor thread’s reading of the instance data and the GoodActor thread’s
writing of it are synchronized on the same lock. The GoodActor’s private in-
stance data has become shared data that must be guarded by a lock. As soon
as you go around the message passing scheme between actors, therefore, you
drop back down into the shared data and locks model, with all the difficulties
you were trying to avoid in the first place by using the actors model.
On the other hand, this does not mean that you should never go around
message passing. Although shared data and locks is very difficult to get right,
it is not impossible. One difference between Scala’s approach to actors and
that of Erlang, in fact, is that Scala gives you the option to combine the actors
and shared data and locks models in the same program.
As an example, imagine you wanted multiple actors to share a common
mutable map. Since the map is mutable, the pure actors approach would be
to create an actor that “owns” the mutable map and define a set of messages
that allows other actors to access it. You could define a message for putting
a key-value pair into the shared map, getting a value given a key, and so
on, for all the operations you need to do on the map. In addition, you’d
need to define messages for sending asynchronous responses to actors that
made queries of the map. Another option, however, is to pass a thread-safe
map, such as ConcurrentHashMap from the Java Concurrency Utilities, in a
message to multiple actors, and let those actors use that map directly.
3
Another benefit is that a message send ensures the message object is safely published to
other threads, as described in Goetz, et. al., Java Concurrency in Practice, p. 49. [Goe06]
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 30.5 Chapter 30 · Actors and Concurrency 620
Although it would be far easier and safer to implement a shared map
via actors than to implement something like ConcurrentHashMap yourself,
since ConcurrentHashMap already exists, you may judge it easier and as
low risk to use that than to implement your own shared map with an actor.
This would also mean that your responses from the shared map could be syn-
chronous, whereas with actors they would need to be asynchronous. Scala’s
actors library gives you the choice.
If you’re considering shared data and locks
When considering whether to combine the actors model with the shared
data and locks model, it is helpful to recall the words of Harry Callahan,
played by Clint Eastwood in the 1971 movie Dirty Harry:
I know what you’re thinking. "Did he fire six shots or only five?" Well,
to tell you the truth, in all this excitement I kind of lost track myself.
But being as this is a .44 Magnum, the most powerful handgun in the
world, and would blow your head clean off, you’ve got to ask yourself
one question: Do I feel lucky? Well, do ya, punk?
Prefer immutable messages
Because Scala’s actors model provides what amounts to a single-threaded en-
vironment inside each actor’s act method, you need not worry about whether
the objects you use in the implementation of this method are thread-safe. You
can use unsynchronized, mutable objects to your hearts content in an act
method, for example, because each act method is effectively confined to
one thread.
4
This is why the actors model is called a share-nothing model—
the data is confined to one thread rather than being shared by many.
There is one exception to the share-nothing rule, however: the data inside
objects used to send messages between actors is “shared” by multiple actors.
As a result, you do have to worry about whether message objects are thread-
safe. And in general, they should be.
4
When using react, different messages could potentially be handled by different
threads, but if so they will be handled sequentially and with sufficient synchronization to
allow you to program under the simplifying assumption that each act method is confined to
a single thread.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index