V. 2.6.

Package umontreal.iro.lecuyer.simprocs

Process-oriented simulation is managed through this package.


Class Summary
Bin A Bin corresponds to a pile of identical tokens, and a list of processes waiting for the tokens when the list is empty.
Condition A Condition is a boolean indicator, with a list of processes waiting for the indicator to be true (when it is false).
DSOLProcessSimulator Represents a simulation process whose actions method is interpreted by the DSOL interpreter, written by Peter Jacobs (
ProcessSimulator Defines a special type of simulator capable of managing processes.
Resource Objects of this class are resources having limited capacity, and which can be requested and released by Process objects.
SimProcess This abstract class provides process scheduling tools.
SSJInterpretationOracle Determines which classes should be interpreted by the DSOL interpreter during process simulation.
ThreadProcessSimulator Represents a process simulator using Java threads for process synchronization.
UserRecord This class represents a record object to store information related to the request of a process for a Resource or for Bin tokens, or when a process waits for a Condition.

Package umontreal.iro.lecuyer.simprocs Description

Process-oriented simulation is managed through this package. A Process can be seen as an active object whose behavior in time is described by a method called actions(). Each process must extend the SimProcess class and must implement this actions() method. Processes are created and can be scheduled to start at a given simulation time just like events. In contrast with the corresponding actions() method of events, the method of processes is generally not executed instantaneously in the simulation time frame. At any given simulation time, at most one process can be active, i.e., executing its actions() method. The active process may create and schedule new processes, kill suspended processes, and suspend itself. A process is suspended for a fixed delay or until a resource becomes available, or a condition becomes true. When a process is suspended or finishes its execution, another process usually starts or resumes.

These processes may represent ``autonomous'' objects such as machines and robots in a factory, customers in a retail store, vehicles in a transportation or delivery system, etc. The process-oriented paradigm is a natural way of describing complex systems and often leads to more compact code than the event-oriented view. However, it is often preferred to use events only, because this gives a faster simulation program, by avoiding the process-synchronization overhead. Most complex discrete-event systems are quite conveniently modeled only with events. In SSJ, events and processes can be mixed freely. The processes actually use events for their synchronization.

The classes Resource, Bin, and Condition provide additional mechanisms for process synchronization. A Resource corresponds to a facility with limited capacity and a waiting queue. A process can request an arbitrary number of units of a resource, may have to wait until enough units are available, can use the resource for a certain time, and eventually releases it. A Bin supports producer/consumer relationships between processes. It corresponds essentially to a pile of free tokens and a queue of processes waiting for the tokens. A producer adds tokens to the pile whereas a consumer (a process) can ask for tokens. When not enough tokens are available, the consumer is blocked and placed in the queue. The class Condition supports the concept of processes waiting for a certain boolean condition to be true before continuing their execution.

Two different implementations of processes are available in SSJ, each one corresponding to a subclass of ProcessSimulator. The first one, called ThreadProcessSimulator, uses Java threads as described in Section 4 of. The second one, DSOLProcessSimulator, is taken from DSOL and was provided to us by Peter Jacobs. Unfortunately, none of these two implementations is fully satisfactory.

Java threads are designed for real parallelism, not for the kind of simulated parallelism required in process-oriented simulation. In the Java Development Kit (JDK) 1.3.1 and earlier, green threads supporting simulated parallelism were available and our original implementation of processes is based on them. But green threads are no longer supported in recent Java runtime environments. True (native) threads from the operating system are used instead. This adds significant overhead and prevents the use of a large number of processes in the simulation. This implementation of processes with threads can be used safely only with the JDK versions 1.3.1 or earlier. A program using the thread-based process view can easily be 10 to 20 times slower than a similar program using the event view only (see for an example).

The second implementation, made by P. Jacobs, stays away from threads. It uses a Java reflection mechanism that interprets the code of processes at runtime and transforms everything into events. A program using the process view implemented with the DSOL interpreter can be 500 to 1000 times slower than the corresponding event-based program but the number of processes is limited only by the available memory.

V. 2.6.

To submit a bug or ask questions, send an e-mail to Pierre L'Ecuyer.