Step 12. Read lines from a file
32.6 A longer example: Parallel discrete event simulation
As a longer example, suppose you wanted to parallelize the discrete event simulation of Chapter 18. Each participant in the simulation could run as its own actor, thus allowing you to speed up a simulation by using more processors. This section will walk you through the process, using code based on a parallel circuit simulator developed by Philipp Haller.
Section 32.6 Chapter 32 ã Actors and Concurrency 741 Overall Design
Most of the design fromChapter 18works fine for both sequential and par- allel discrete event simulation. There are events, and they happen at desig- nated times, processing an event can cause new events to be scheduled, and so forth. Likewise, a circuit simulation can be implemented as a discrete event simulation by making gates and wires participants in the simulation, and changes in the wires the events of the simulation. The one thing that would be nice to change would be to run the events in parallel. How can the design be rearranged to make this happen?
The key idea is to make each simulated object an actor. Each event can then be processed by the actor where most of that event’s state lies. For circuit simulation, the update of a gate’s output can be processed by the actor corresponding to that gate. With this arrangement, events will naturally be handled in parallel.
In code, it is likely that there will be some common behavior between different simulated objects. It makes sense, then, to define a traitSimulant that can be mixed into any class to make it a simulated object. Wires, gates, and other simulated objects can mix in this trait.
trait Simulant extends Actor class Wire extends Simulant
So far so good, but there are a few design issues to work out, several of which do not have a single, obviously best answer. For this chapter, we present a reasonable choice for each design issue that keeps the code concise.
There are other solutions possible, though, and trying them out would make for good practice for anyone wanting experience programming with actors.
The first design issue is to figure out how to make the simulation par- ticipants stay synchronized with the simulated time. That is, participant A should not race ahead and process an event at time tick 100 until all other ac- tors have finished with time tick 99. To see why this is essential, imagine for a moment that simulant A is working at time 90 while simulant B is working at time 100. It might be that participant A is about to send a message that changes B’s state at time 91. B will not learn this until too late, because it has already processed times 92 to 99. To avoid this problem, the design ap- proach used in this chapter is that no simulant should process events for time nuntil all other simulants are finished with timen−1.
Section 32.6 Chapter 32 ã Actors and Concurrency 742 That decision raises a new question, though: how do simulants know when it’s safe to move forward? A straightforward approach is to have a
“clock” actor that keeps track of the current time and tells the simulation participants when it is time to move forward. To keep the clock from moving forward before all simulants are ready, the clock can ping actors at carefully chosen times to make sure they have received and processed all messages for the current time tick. There will bePing messages that the clock sends the simulants, and Pong messages that the simulants send back when they are ready for the clock to move forward.
case class Ping(time: Int)
case class Pong(time: Int, from: Actor)
Note that these messages could be defined as having no fields. However, the timeandfrom fields add a little bit of redundancy to the system. The
time field holds the time of a ping, and it can be used to connect a Pong with its associatedPing. Thefromfield is the sender of aPong. The sender of a Pingis always the clock, so it does not have a fromfield. All of this information is unnecessary if the program is behaving perfectly, but it can simplify the logic in some places, and it can greatly help in debugging if the program has any errors.
One question that arises is how a simulant knows it has finished with the current time tick. Simulants should not respond to a Ping until they have finished all the work for that tick, but how do they know? Maybe another actor has made a request to it that has not yet arrived. Maybe a message one actor has sent another has not been processed yet.
It simplifies the answer to this question to add two constraints. First, assume that simulants never send each other messages directly, but instead only schedule events on each other. Second, they never post events for the current time tick, but only for times at least one tick into the future. These two constraints are significant, but they appear tolerable for a typical simula- tion. After all, there is normally some non-zero propagation delay whenever two components of a system interact with each other. Further, at worst, time ticks can be made to correspond to shorter time intervals, and information that will be needed in the future can be sent ahead of time.
Other arrangements are possible. Simulants could be allowed to send messages directly to each other. However, if they do so, then there would need to be a more sophisticated mechanism for deciding when it is safe for an actor to send back aPong. Each simulant should delay responding to a
Section 32.6 Chapter 32 ã Actors and Concurrency 743
Pinguntil any other simulants it has made requests to are finished processing those requests. To ensure this property, you would need the simulants to pass each other some extra information. For now, assume that simulants don’t communicate with each other except via the simulation’s agenda.
Given that decision, there may as well be a single agenda of work items, and that agenda may as well be held by the clock actor. That way, the clock can wait to send out pings until it has sent out requests for all work items at the current time. Actors then know that whenever they receive aPing, they have already received from the clock all work items that need to happen at the current time tick. It is thus safe when an actor receives aPingto immediately send back aPong, because no more work will be arriving during the current time tick. Taking this approach, aClockhas the following state:
class Clock extends Actor { private var running = false private var currentTime = 0
private var agenda: List[WorkItem] = List() }
The final design issue to work out is how a simulation is set up to begin with. A natural approach is to create the simulation with the clock stopped, add all the simulants, connect them all together, and then start the clock. The subtlety is that you need to be absolutely sure that everything is connected before you start the clock running! Otherwise, some parts of the simulation will start running before they are fully formed.
How do you know when the simulation is fully assembled and ready to start? There are again multiple ways to approach this problem. The simple way adopted in this chapter is to avoid sending messages to actors while setting the simulation up. That way, once the last method call returns, you know that the simulation is entirely constructed. The resulting coding pattern is that you use regular method calls to set the simulation up, and you use actor message sends while the simulation is running.
Given the preceding decisions, the rest of the design is straightforward.
AWorkItemcan be defined much like inChapter 18, in that it holds a time and an action. For the parallel simulation, however, the action itself has a different encoding. InChapter 18, actions are represented as zero-argument functions. For parallel simulation, it is more natural to use a target actor and a message to be sent to that actor:
Section 32.6 Chapter 32 ã Actors and Concurrency 744
case class WorkItem(time: Int, msg: Any, target: Actor)
Likewise, theafterDelaymethod for scheduling a new work item becomes an AfterDelay message that can be sent to the clock. Just as with the
WorkItemclass, the zero-argument action function is replaced by a message and a target actor:
case class AfterDelay(delay: Int, msg: Any, target: Actor)
Finally, it will prove useful to have messages requesting the simulation to start and stop:
case object Start case object Stop
That’s it for the overall design. There is aClockclass holding a current time and an agenda, and a clock only advances the clock after it has pinged all of its simulants to be sure they are ready. There is a Simulanttrait for simulation participants, and these communicate with their fellow simulants by sending work items to the clock to add to its agenda. The next section will take a look now at how to implement these core classes.
Implementing the simulation framework
There are two things that need implementing for the core framework: the
Clock class and theSimulant trait. Consider the Clockclass, first. The necessary state of a clock is as follows:
class Clock extends Actor { private var running = false private var currentTime = 0
private var agenda: List[WorkItem] = List() private var allSimulants: List[Actor] = List() private var busySimulants: Set[Actor] = Set.empty
A clock starts out withrunning set tofalse. Once the simulation is fully initialized, the clock will be sent the Startmessage andrunning will be- come true. This way, the simulation stays frozen until all of its pieces have been connected together as desired. It also means that, since all of the sim- ulants are also frozen, it is safe to use regular method calls to set things up instead of needing to use actor message sends.
Section 32.6 Chapter 32 ã Actors and Concurrency 745 A clock may as well go ahead and start running as an actor once it is created. This is safe, because it will not actually do anything until it receives aStartmessage:
start()
A clock also keeps track of the current time (currentTime), the list of participants managed by this clock (allSimulants), and the list of partic- ipants that are still working on the current time tick (busySimulants). A list is used to holdallSimulants, because it is only iterated through, but a set is used forbusySimulantsbecause items will be removed from it in an unpredictable order. Once the simulator starts running, it will only advance to a new time whenbusySimulantsis empty, and whenever it advances the clock, it will setbusySimulantstoallSimulants.
To set up a simulation, there is going to be a need for a method to add new simulants to a clock. It may as well be added right now:
def add(sim: Simulant) {
allSimulants = sim :: allSimulants }
That’s the state of a clock. Now look at its activity. Its main loop alter- nates between two responsibilities: advancing the clock, and responding to messages. Once the clock advances, it can only advance again when at least one message has been received, so it is safe to define the main loop as an alternation between these two activities:
def act() { loop {
if (running && busySimulants.isEmpty) advance()
reactToOneMessage() }
}
The advancement of time has a few parts beyond simply incrementing the
currentTime. First, if the agenda is empty, and the simulation is not just starting, then the simulation should exit. Second, assuming the agenda is non-empty, all work items for time currentTime should now take place.
Section 32.6 Chapter 32 ã Actors and Concurrency 746 Third, all simulants should be put on thebusySimulantslist and sentPings.
The clock will not advance again until allPings have been responded to:
def advance() {
if (agenda.isEmpty && currentTime > 0) {
println("** Agenda empty. Clock exiting at time "+
currentTime+".") self ! Stop
return }
currentTime += 1
println("Advancing to time "+currentTime) processCurrentEvents()
for (sim <- allSimulants) sim ! Ping(currentTime)
busySimulants = Set.empty ++ allSimulants }
Processing the current events is simply a matter of processing all events at the top of the agenda whose time iscurrentTime:
private def processCurrentEvents() {
val todoNow = agenda.takeWhile(_.time <= currentTime) agenda = agenda.drop(todoNow.length)
for (WorkItem(time, msg, target) <- todoNow) { assert(time == currentTime)
target ! msg }
}
There are three steps in this method. First, the items that need to occur at the current time are selected usingtakeWhileand saved into theval todoNow. Second, those items are dropped from the agenda by usingdrop. Finally, the items to do now are looped through and sent the target message. Theassert
is included just to guarantee that the scheduler’s logic is sound.
Given this ground work, handling the messages that a clock can receive is straightforward. AnAfterDelaymessage causes a new item to be added to the work queue. APongcauses a simulant to be removed from the list of
Section 32.6 Chapter 32 ã Actors and Concurrency 747 busy simulants. Startcauses the simulation to begin, andStopcauses the clock to stop:
def reactToOneMessage() { react {
case AfterDelay(delay, msg, target) =>
val item = WorkItem(currentTime + delay, msg, target) agenda = insert(agenda, item)
case Pong(time, sim) =>
assert(time == currentTime)
assert(busySimulants contains sim) busySimulants -= sim
case Start => running = true case Stop =>
for (sim <- allSimulants) sim ! Stop
exit() }
}
Theinsertmethod, not shown, is exactly like that ofListing 18.8. It inserts its argument into the agenda while being careful to keep the agenda sorted.
That’s the complete implementation ofClock. Now consider how to im- plementSimulant. Boiled down to its essence, aSimulantis any actor that understands and cooperates with the simulation messages Stop and Ping. Itsactmethod can therefore be as simple as this:
def act() { loop {
react {
case Stop => exit() case Ping(time) =>
if (time == 1) simStarting() clock ! Pong(time, self)
case msg => handleSimMessage(msg) }
} }
Section 32.6 Chapter 32 ã Actors and Concurrency 748
trait Simulant extends Actor { val clock: Clock
def handleSimMessage(msg: Any) def simStarting() { }
def act() { loop {
react {
case Stop => exit() case Ping(time) =>
if (time == 1) simStarting() clock ! Pong(time, self)
case msg => handleSimMessage(msg) }
} } start() }
Listing 32.7ãTheSimulanttrait.
Whenever a simulant receivesStop, it exits. If it receives aPing, it responds with aPong. If thePingis for time 1, thensimStartingis called before the
Pongis sent back, allowing subclasses to define behavior that should happen when the simulation starts running. Any other message must be interpreted by subclasses, so it defers to an abstracthandleSimMessagemethod.
There are two abstract members of a simulant: handleSimMessageand
clock. A simulant must know its clock so that it can reply toPingmessages and schedule new work items. Putting it all together, theSimulanttrait is as shown inListing 32.7. Note that a simulant goes ahead and starts running the moment it is created. This is safe and convenient, because it will not actually do anything until its clock sends it a message, and that should not happen until the simulation starts and the clock receives aStartmessage.
That completes the framework for parallel event simulation. Like its sequential cousin inChapter 18, it takes surprisingly little code.
Section 32.6 Chapter 32 ã Actors and Concurrency 749 Implementing a circuit simulation
Now that the simulation framework is complete, it’s time to work on the implementation of circuits. A circuit has a number of wires and gates, which will be simulants, and a clock for managing the simulation. A wire holds a boolean signal—either high (true) or low (false). Gates are connected to a number of wires, some of which are inputs and others outputs. Gates compute a signal for their output wires based on the state of their input wires.
Since the wire, gates, etc., of a circuit are only used for that particular circuit, their classes can be defined as members of a Circuitclass, just as with the currency objects of Section 20.10. The overallCircuitclass will therefore have a number of members:
class Circuit {
val clock = new Clock // simulation messages // delay constants
// Wire and Gate classes and methods // misc. utility methods
}
Now look at each of these members, one group at a time. First, there are the simulation messages. Once the simulation starts running, wires and gates can only communicate via message sends, so they will need a message type for each kind of information they want to send each other. There are only two such kinds of information. Gates need to tell their output wires to change state, and wires need to inform the gates they are inputs to whenever their state changes:
case class SetSignal(sig: Boolean)
case class SignalChanged(wire: Wire, sig: Boolean)
Next, there are several delays that must be chosen. Any work item scheduled with the simulation framework—including propagation of a signal to or from a wire—must be scheduled at some time in the future. It is unclear what the precise delays should be, so those delays are worth putting intovals. This way, they can be easily adjusted in the future:
val WireDelay = 1 val InverterDelay = 2
Section 32.6 Chapter 32 ã Actors and Concurrency 750
val OrGateDelay = 3 val AndGateDelay = 3
At this point it is time to look at theWireandGateclasses. Consider wires, first. A wire is a simulant that has a current signal state (high or low) and a list of gates that are observing that state. It mixes in theSimulanttrait, so it also needs to specify a clock to use:
class Wire(name: String, init: Boolean) extends Simulant { def this(name: String) { this(name, false) }
def this() { this("unnamed") } val clock = Circuit.this.clock clock.add(this)
private var sigVal = init
private var observers: List[Actor] = List()
The class also needs ahandleSimMessagemethod to specify how it should respond to simulation messages. The only message a wire should receive is
SetSignal, the message for changing a wire’s signal. The response should be that if the signal is different from the current signal, the current state changes, and the new signal is propagated:
def handleSimMessage(msg: Any) { msg match {
case SetSignal(s) =>
if (s != sigVal) { sigVal = s
signalObservers() }
} }
def signalObservers() { for (obs <- observers)
clock ! AfterDelay(
WireDelay,
SignalChanged(this, sigVal), obs)
}
Section 32.6 Chapter 32 ã Actors and Concurrency 751 The above code shows howchangesin a wire’s signal are propagated to any gates watching it. It’s also important to pass the initial state of a wire to any observing gates. This only needs to be done once, when the simulation starts up. After that, gates can simply store the result of the most recent
SignalChangedthey have received. Sending out the initial signal when the simulation starts is as simple as providing asimStarting()method:
override def simStarting() { signalObservers() }
There are now just a few more odds and ends about wires. Wires need a method for connecting new gates, and they could use a nice toString
method:
def addObserver(obs: Actor) { observers = obs :: observers }
override def toString = "Wire("+ name +")"
That is everything you need for wires. Now consider gates, the other major class of objects in a circuit. There are three fundamental gates that would be nice to define: And,Or, andNot. All of these share a lot of behavior, so it is worth defining an abstractGateclass to hold the commonality.
A difficulty in defining thisGateclass is that some gates have two input wires (And, Or) while others have just one (Not). It would be possible to model this difference explicitly. However, it simplifies the code to think of all gates as having two inputs, where Notgates simply ignore their second input. The ignored second input can be set to some dummy wire that never changes state fromfalse:
private object DummyWire extends Wire("dummy")
Given this trick, the gate class will come together straightforwardly. It mixes in theSimulanttrait, and its one constructor accepts two input wires and one output wire:
abstract class Gate(in1: Wire, in2: Wire, out: Wire) extends Simulant {
There are two abstract members of Gatethat specific subclasses will have to fill in. The most obvious is that different kinds of gates compute a dif-