Overview | Package | Class | Tree | Deprecated | Index | Help
| SSJ V. 2.1.1.
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

## 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 `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.

Overview | Package | Class | Tree | Deprecated | Index | Help
| SSJ V. 2.1.1.
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

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