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.

42<br />

Implementation<br />

confirm a provisional simulation end state that might be reached by one of the Logical<br />

Processes.<br />

When the end of the simulation is reached then the Simulation Controller will ensure<br />

that the partial models in all Logical Processes are set to the correct and consistent end<br />

state and it will collect information from all Logical Processes in order to assemble and<br />

output the post simulation report.<br />

5.1.2 Transaction Chain and Scheduling<br />

Thomas J. Schriber gives an overview in section 4. and 7. of [26] on how the<br />

Transaction chains and the scheduling work in the original GPSS/H implementation.<br />

The scheduling and the Transaction chains for the parallel transaction-oriented simulator<br />

of this work will be based on his description but with some significant differences. Only<br />

one Transaction chain is used containing Transactions for current and future simulation<br />

time in a sorted order. The Transactions within the chain are first sorted ascending by<br />

their next moving time and Transactions for the same time are also sorted descending by<br />

their priority. Transactions will be taken out of the chain before they are moved and put<br />

back into the chain after they have been moved (unless the Transaction has been<br />

terminated). The functionality to put a Transaction back into the chain will do so at the<br />

right position ensuring the correct sort order of the Transactions within the chain. The<br />

scheduling will be slightly simpler than described in [26] because no “Model’s Status<br />

changed flag” will be needed.<br />

Another difference is that in order to keep the time management as simple as possible<br />

the proposed parallel simulator will restrict the simulation time and time related<br />

parameters to integer values instead of floating point values. At first this might seem<br />

like a major restriction but it is not because decimal places can be represented using<br />

scaling. If for instance a simulation time with three decimal places is needed for a<br />

simulation then a scale of 1000:1 can be used, which means 1000 time units of the<br />

parallel simulator represent one second of simulation time or a single time unit<br />

represents 1ms. The Java integer type long will be used for time values providing a<br />

large value range that allows flexible scaling for different required precisions.<br />

The actual scheduling will be implemented using a SimulationEngine class. This class<br />

will for instance contain the functionality for moving Transactions, updating the

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

Saved successfully!

Ooh no, something went wrong!