Previous fileTop of DocumentContentsIndex pageNext file
Apache C++ Standard Library User's Guide

11.3 Example Program: Event-Driven Simulation

An extended example will now illustrate one of the more common uses of a priority_queues, which is to support the construction of a simulation model. A discrete event-driven simulation is a popular simulation technique. Objects in the simulation model objects in the real world, and are programmed to react as much as possible as the real objects would react. A priority_queue is used to store a representation of events that are waiting to happen. This queue is stored in order, based on the time the event should occur, so the smallest element will always be the next event to be modeled. As an event occurs, it can spawn other events. These subsequent events are placed into the queue as well. Execution continues until all events have been processed.

NOTE -- The complete version of the ice cream store simulation program is in icecream.cpp.

Events can be represented as subclasses of a base class, which we call event. The base class simply records the time at which the event will take place. A pure virtual function named processEvent is invoked to execute the event:

The simulation queue needs to maintain a collection of different types of events, sometimes called a heterogeneous collection. Each different form of event is represented by a subclass of class event, but not all events have the same exact type. For this reason the collection must store pointers to events, instead of the events themselves. Since the containers maintain pointers to values, not the values themselves, the programmer is responsible for managing the memory for the objects being manipulated.

Since comparison of pointers cannot be specialized on the basis of the pointer types, we must instead define a new comparison function for pointers to events. In the C++ Standard Library we do this by defining a new structure whose sole purpose is to define the function invocation operator()() in the appropriate fashion. Since in this particular example we want to use the priority_queue to return the smallest element each time, rather than the largest, the order of the comparison is reversed, as follows:

NOTE -- We use a priority queue as a structure for quickly discovering the smallest element in a sequence. If, instead, your problem requires the discovery of the largest element, there are various possibilities. One is to supply the inverse operator as either a template argument or the optional comparison function argument to the constructor. If you are defining the comparison argument as a function, as in the example problem, another solution is to simply invert the comparison test.

We are now ready to define the class simulation, which provides the structure for the simulation activities. The class simulation provides two functions: the first is used to insert a new event into the queue, while the second runs the simulation. A data member is also provided to hold the current simulation time:

Notice the declaration of the priority_queue used to hold the pending events. In this case we are using a vector as the underlying container, but we could just as easily have used a deque.

The heart of the simulation is the member function run(), which defines the event loop. This procedure makes use of three of the five priority_queue operations, namely top(), pop(), and empty(). It is implemented as follows:

11.3.1 Example Program: An Ice Cream Store Simulation

To illustrate the use of our simulation framework, this example program gives a simple simulation of an ice cream store. Such a simulation might be used, for example, to determine the optimal number of chairs that should be provided, based on assumptions such as the frequency with which customers arrive, the length of time they stay, and so on.

Our store simulation is based around a subclass of class simulation, defined as follows:

There are three basic activities associated with the store: arrival, ordering and eating, and leaving. This is reflected not only in the three member functions defined in the simulation class, but in three separate subclasses of event.

The member functions associated with the store simply record the activities taking place, producing a log that can later be studied to evaluate the simulation.

As we noted already, each activity is matched by a subclass of event. Each subclass of event includes an integer data member, which represents the size of a group of customers. The arrival event occurs when a group enters. When executed, the arrival event creates and installs a new instance of the order event. The function randomInteger() is used to compute a random integer between 1 and the argument value (see Section 2.2.5).

An order event similarly spawns a leave event:

Finally, leave events free up chairs, but do not spawn any new events:

To run the simulation we simply create some number of initial events (say, 30 minutes worth), then invoke the run() member function:

Previous fileTop of DocumentContentsIndex pageNext file