3.1 MB - Evernote
3.1 MB - Evernote
3.1 MB - Evernote
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
43<br />
Implementation<br />
simulation time and also the Transaction chain itself. The SimulationEngine class will<br />
be implemented as part of the Basic GPSS Simulation Engine implementation phase<br />
detailed in section 5.2.2 and a description of how the scheduling was implemented can<br />
be found in 5.<strong>3.1</strong>.<br />
5.1.3 Generation and Termination of Transactions<br />
Performing transaction-oriented simulation in a parallel simulator also has an influence<br />
on how Transactions are generated and how they are terminated.<br />
Generating Transactions<br />
Transactions are generated in the GENERATE blocks of the simulation. During the<br />
generation each Transaction receives a unique numerical ID that identifies the<br />
Transaction during the rest of the simulation. In a parallel transaction-oriented simulator<br />
GENERATE blocks can exist in any of the model partitions and therefore in any of the<br />
LPs. This requires a scheme, which ensures that the Transaction IDs generated in each<br />
LP are unique across the overall parallel simulation. Ideally such a scheme requires as<br />
little communication between the LPs as possible.<br />
The scheme used for this parallel simulator will generate unique Transaction IDs<br />
without any additional communication overhead. This is achieved by partitioning the<br />
value range of the numeric IDs according to the number of partitions in the simulation<br />
model. The only requirement of this scheme is that all LPs are aware of the total number<br />
of partitions and LPs within the simulation. This information will be passed to them<br />
during the initialisation. The used scheme is based on an offset that depends on the total<br />
number of LPs. Each LP has its own counter that is used to generate unique Transaction<br />
IDs. These counters are initialised with different starting values and the same offset is<br />
used for incrementing the counters when one of their values has been used for a<br />
Transaction ID. A simulation with n LPs (i.e. n partitions) will use the offset n to<br />
increment the local Transaction ID counters and each LP will initialise its counter with<br />
its own number in the list of LPs. In a simulation with 3 LPs, LP1 would initialise its<br />
counter to the value 1, LP2 to 2 and LP3 to 3 and the increment offset used would be the<br />
total number of LPs which is 3. The sequence of IDs generated by these LPs would be<br />
LP1: 1, 4, 7, … and by LP2: 2, 5, 8, … and by LP3: 3, 6, 9, … and so forth. Further<br />
advantages of this scheme are that it partitions the possible ID value range into equally