Multithreading: Replace PRNG with own Wrapper Class and Buffer Its State
This MR
- Introduces the PRNG wrapper around
std::mt19937_64
(64-bit Mersenne Twister Engine from STL) - Introduces a new log level below
TRACE
:PRNG
can now be used to follow random number requests throughout the framework. Also makes debugging in multiple threads easier. - Replaces all
std::mt19937_64
in the framework by our ownRandomNumberGenerator
- Implements storing and restoring of the PRNG state in the event when buffering / run_in_order happens and updates the documentation accordingly.
In addition, it could be discussed to change the way we provide pseudo-random numbers to the initialization of modules. Previously, the ModuleManager sets a temporary PRNG via module->set_random_generator(&prng)
, then calls module->init()
and afterwards resets it using module->set_random_generator(nullptr)
. Therefore the module can request random numbers via getRandomSeed()
only during its init()
function. Alternatively, we could directly provide a PRNG through the init(...)
function of the module.
Pros:
- No need to change
init()
interface. - Module never has access to PRNG itself, no risk of module copying pointer.
Cons:
- A bit clunky.
Opinions?