Contents

In the process-oriented view, real-world entities are categorized into permanent and temporary entities. A permanent entity, modeled as a resource, exists throughout the simulation duration. A temporary entity, modeled as a process, can be created dynamically at any point during the simulation and thus does not exist throughout the simulation duration.

2.1  Processes

During its entire simulation lifetime, a process can be in any one of five states, namely active, blocked, pending, non-existent or holding, as shown in Figure 2.1 further down this page. When a process is initially created in the simulation program, it is classified as non-existent relative to the system until it is activated, which virtually causes it to enter the pending state. Now, the process is officially within the system, and it is scheduled for execution at a simulation time corresponding to the timestamp of the process. The timestamp of a process here refers to the global virtual time at which the process is to undertake the next activity specified by its event tag.

The process enters the active state when it begins its execution, at the point whereby the simulation clock advances to the timestamp of the process. During the execution, it may request service at a specific resource in the system, and when the resource is unavailable, the process halts execution temporarily, thus, it is considered to be in the blocked state. A process can even suspend itself during its turn of execution, causing it to fall into the holding state. Once in this state, the process will remain suspended till another process reactivates it with a higher timestamp, causing it to return to the pending state. It will become active when the simulation clock advances to its reactivation time. A process is also in the non-existent state when it has completed its thread of execution and ceases to exist officially in the simulation system.

Figure 2.1 - SPaDES/Java state transition diagram

2.2  Resources

Resources are the permanent simulation entities present to provide services to the active processes upon request. Each resource comprises of a default FIFO queue, created when the resource is constructed, and whose function is to maintain the arrival of processes to the resource. When the resource is busy serving another process, an arrival process is subsequently queued in this resource queue. The process is serviced immediately when the resource is idle. Each resource is really a collection set of service units, which is the basic functional unit of a resource. In our implementation, when an active process requests for service at any particular resource, the total number of service units required must be explicitly mentioned.