26.08.2013 Views

3.1 MB - Evernote

3.1 MB - Evernote

3.1 MB - Evernote

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!