Programming with actors was a new concept to me until I tried it out in Scala. It’s appears to be one of Scala’s most celebrated features, judging by the official blurb. Actors was a daunting word at first but it really ends up being a very simple concept.
Actors are a programming model for concurrent programming. With conventional mutex/monitor based programming in Java, say, programmers hold and release locks (the synchronized keyword) to achieve safe concurrency. Condition variables are used for thread communication (the wait and notify family of functions on java.lang.Object). Communication is synchronous: a typical case would be that you change some condition, invoke notifyAll to wake up threads waiting on that condition, and then they can take over the relevant lock and proceed to do some processing.
An actor is a unit of execution with an asynchronous message queue. Actors can receive messages from other actors or send messages to other actors at any time, however, the messages wait in the receiving actor’s “mailbox” until the actor has time to receive it.
As a simple example, let’s develop a program that converts text files to upper case using actors. The program will have an “Input” actor, an “Output” actor, and a number of “UpperCase” actors that do the processing. First the Input actor:
import scala.actors._
import java.io._
class Input(in: BufferedReader) extends Actor {
def act() {
while(true) {
receive {
case Next => { sender ! Line(in.readLine()) }
}
}
}
} |
import scala.actors._
import java.io._
class Input(in: BufferedReader) extends Actor {
def act() {
while(true) {
receive {
case Next => { sender ! Line(in.readLine()) }
}
}
}
}
It’s worth noting that the Actor system is implemented completely in the libraries, outside of the core language. Actors are not first class constructs, but sometimes look as if they were. The act method is where actors begin their execution. The receive method causes them to block and wait for a message, which we may pattern match on. The sender variable corresponds to whoever sent the last message received, and the ‘!’ operator sends a message. So whenever this actor receives the Next message, it will respond with the next line from a buffered reader.
Then, the UpperCase actor:
import scala.actors._
case class Next
case class Line(x: String)
class UpperCase(input: Actor, out: Actor) extends Actor {
def act() {
while(true)
{
input ! Next
receive {
case Line(x:String) => { out ! x.toUpperCase() }
}
}
}
} |
import scala.actors._
case class Next
case class Line(x: String)
class UpperCase(input: Actor, out: Actor) extends Actor {
def act() {
while(true)
{
input ! Next
receive {
case Line(x:String) => { out ! x.toUpperCase() }
}
}
}
}
This actor is created with in- and output actors as its constructor parameters. It continually asks the input actor for a new line, converts it to upper case, and sends it to the output actor. Also note the case classes here, which are for pattern matching only. They are a bit like algebraic data types in Haskell.
Finally, the Output actor:
import scala.actors._
class Output extends Actor {
def act() {
while(true)
{
receive {
case x:String => { println(x) }
}
}
}
} |
import scala.actors._
class Output extends Actor {
def act() {
while(true)
{
receive {
case x:String => { println(x) }
}
}
}
}
And then we have to tie it all together:
import java.io._
object Demonstration {
val reader = new BufferedReader(new InputStreamReader(System.in))
def main(args: Array[String]) {
val in = new Input(reader)
in.start
val out = new Output()
out.start
1.to(5).foreach(x => {
val tr = new UpperCase(in, out)
tr.start
})
}
} |
import java.io._
object Demonstration {
val reader = new BufferedReader(new InputStreamReader(System.in))
def main(args: Array[String]) {
val in = new Input(reader)
in.start
val out = new Output()
out.start
1.to(5).foreach(x => {
val tr = new UpperCase(in, out)
tr.start
})
}
}
Here I abuse the foreach notation slightly to create 5 parallel text processors. Each actor runs on its own thread (though there are ways to prevent this if one wants very large numbers of actors). Now of course, the lines will probably be output in the wrong order. Another obvious shortcoming is that there is no clean shutdown protocol that terminates all the actors when the input stream is fully read. Solving these problems is outside of the scope of this article.
Some other interesting resources on actors: the official tutorial, the papers (slightly more academic but accessible to the monomorphic reader, I imagine). Debasish highlights how actors can be used to get threadless concurrency, Erlang-style.
