[random number generator] made cAsyncmodule inherit from cNumbergenerator as well.
[nullduration] cosmetic changes
[nullduration] moved asyncModuleLocks to earlier position and added getProcessingDelay return value that makes the event get handled sequentially:We have to lock before getProcessingDelay is called, and must only be released, once the corresponding event has been handled. This is because in the meantime, other events could alter the module and therefore change the outcome of getProcessingDelay nondeterministically....
[numGen] overloaded method calls in casyncmodule to make numGen-> referenciations unnecessary[nullduration] the barriermessage is now scheduled BEFORE the children of an event
[nullduration] bugfix: correcty insert barriermsgs with their parentID and parentArrivalTime being that of the corresponding event.
[nullduration] added- runtimeexception when wrong priority is scheduled- NOBARRIER-threadstate now uses UINT_MAX for barriers
[random-number-generator] cAsyncModules now take ini input for RNG seeding- the parameter number-local-rngs specifies how many local random number generators are beeing created for the module- the parameter local-rng-seed takes a string of whitespace-seperated seeds, that are beeing used to seed the corresponding RNG. Example:...
[nullduration] BARRIER: the additional barrier information is now always set in the scheduler, although this might not be necessary everytime.
[nullduration] added insertOrder comparison to the NOBARRIER comparison operators in the threadpool. These are necessary because during initialization, the rest of the parameters dont provide an unambigious ordering
[nullduration]- implemented rest of nullduration algorithm for both barrier based approach as well as NOBARRIER.-- barrier based approach: the barriers are now placed according to ordering-- nobarrier: the comparison operators have been extended
- hopefully fixed cache line size alignment
Also available in: Atom