|
SSJ V. 2.6. |
||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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 . |
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.
|
SSJ V. 2.6. |
||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |