Package umontreal.iro.lecuyer.simprocs

Process-oriented simulation is managed through this package.

See:
Description

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 (http://www.tbm.tudelft.nl/webstaf/peterja/index.htm).
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 umontreal.iro.lecuyer.simprocsSimProcess 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[#!sFRA77a!#,#!sBIR86a!#,#!sKRE86a!#,#!sLAW00a!#] 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 umontreal.iro.lecuyer.simprocsResource, umontreal.iro.lecuyer.simprocsBin, and umontreal.iro.lecuyer.simprocsCondition provide additional mechanisms for process synchronization. A umontreal.iro.lecuyer.simprocsResource 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 umontreal.iro.lecuyer.simprocsBin 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 umontreal.iro.lecuyer.simprocsCondition 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[#!sLEC02a!#]. The second one, DSOLProcessSimulator, is taken from DSOL[#!iJAC05a!#,#!sJAC04a!#] 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[#!sLEC05a!#] 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.