3.1 MB - Evernote

Parallel Transaction-oriented Simulation
because this read access should happen at the simulation time 5 which is before the
event e2 at LP1 overwrote the value of o1. Instead event e4 reads the value of o1 as it
appears at the simulation time 12.
LP1
Current simulation time = 12
Current event = e3
e3 12, ...
Object
o1
Event list Event list
...
e2 8, write o1
e1 3, read o1
...
Future events
Current event position
Past events
Figure 7: Accessing objects in other LPs
LP2
Current simulation time = 5
Current event = e4
e4 5, read o1
Because accessing an object within another LP is an action that is linked to a specific
point of simulation time it can also be viewed as an event according to the description of
events in section 4.1.1. Like other events they have to be executed in the correct causal
order. This means that event e4 that is reading the value of object o1 has to happen at the
simulation time 5. Sending this event to LP1 would cause LP1 to roll back to the
simulation time 5 so that e4 would read the correct value.
Treating the access to objects as a special kind of event solves the problem mentioned
above. Such a solution can also be applied to transaction-oriented simulation by
implementing a simulation scheduler that besides Transactions can also handle these
kinds of object access events. Alternatively the object access could be implemented as a
pseudo Transaction that does not point to its next block but instead to an access method
that when executed performs the object access and for a read access returns the value.
Such a pseudo Transaction would send the value back to the originating LP and then be
deleted. Depending on the synchronisation algorithm it can also be useful treat read and
write access differently. If for instance an optimistic synchronisation algorithm is used
that saves system states for possible required rollbacks then rollbacks as a result of
23
...
...