- Parallel discrete event simulation (PDES) refers to the execution
of a single discrete event simulation program on a parallel computer.
- A discrete event simulation model assumes the system being simulated
only changes state at a discrete points in simulated time.
- The simulation model jumps from one state to another upon the
occurrence of an event.
- In a real world system model, many things (events) can occur
at the about same time, yet few take place at the exact same moment.
Also, they don't have a regular interval in between occurrances.
- Asynchronous systems where events are not synchronized by a
global clock.
- A possible mechanism of PDES is to use lock-step execution
using a global simulation clock among many processors. At each step of
simulated time, event lists on different processors are checked and
the events due in time are executed.
- This approach performs very poorly because very few events
would have the exact same time.
- Concurrent execution of events at different points
in simulated time is required! This introduces interesting synchronization
problems that are at the heart of the PDES problem.
- Sequential simulations typically utilize three data structures:
- the state variables that describe the state of
the system,
- an event list containing all pending events that
have been scheduled, but have not yet taken effect, and
- a global clock variable to denote how far the simulation
has progressed.
- In this execution paradigm, it is crucial that one always select
the smallest timestamped event from the event list as the one to
be processed next.
- If an event with larger timestamp were executed before a smaller
one that would schedule this larger timestamped event, an logic error
would occur. We call this type of errors causality
errors.
Example: if a customer's departure event is processed before
its arrival event, a causality error occured.
- The greatest opportunity in parallel simulation is to process
events concurrently on different processors.
- A typical strategy is to map each physical process to a logical
process (LP) and each LP proceeds simulation on its own pace.
Example: if we are to simulate a gas station with two independent
attendants, they form naturally two LPs, each of which can execute
simulation of its own.
- One can ensure that no causality errors occur if one adheres
to the following constraint:
- Local Causality Constraint
- A discrete event simulation,
consisting of logical processes (LPs) that interact exclusively
by exchanging timestamped messages, obeys the local causality
constraint if and only if each LP processes events in non-decreasing
timestamp order.
The above LCC essentially says if events are processed in non-decreasing
timestamp order, then we say it obeys the causality constraint; if events
are not processed in non-decreasing timestamp order, then we say it
does not obey the causality constraint.
- Adherence to this constraint is sufficient, though not always
necessary, to guarantee that no causality errors occur. In another words,
violating causality constraint may not always result in simulation error.
This is because two events within a single LP may be independent of
each other, in which case processing them out of timestamp sequence
does not lead to causality error.
Example: a supermarket has a service desk and a number of check-out
lines. The customers who go through service desk can be considered
independent of those who go through check-out lines. If we process
them out of timestamp order, it will not lead to causality error.
On the other hand, if in the same check-out line for a single customer,
if we process the bagging event before the check-out event,
a causality error has occured.
- The challenge in PDES is to execute LPs concurrently and lead
to correct simulation results.
- PDES mechanisms can be divided into two categories: conservative
and optimistic.
Conservative approaches strictly avoid the possibility of any
causality error. Typically these approaches reply on some strategy to
determine if it safe to process an event.
Optimistic approaches use a detect and recover strategy: causality
errors are allowed, but detected, and a rollback mechanism
is invoked to recover the errors.
