[riot-devel] To global seed or not to global seed
list-riot at cgundogan.de
Wed Mar 8 00:18:28 CET 2017
for quite some time now we have semi-active discussions (mostly on
GitHub) about various PRNG and seeding concepts. In this mail I merely
want to focus on the scope of our PRNG implementations' seeds/states.
Currently, all function calls in our PRNG implementations and the
abstraction layer `sys/random` do *not* allow to pass a custom state.
This means, there is *one* global state, that is overwritten with
successive calls to `random_init()`, not necessarily from the same
thread. At the moment, `auto_init` is the only instance, that calls
`random_init` (albeit with `0`, but this is another story). So
everything seems to be OK for now (?), but will it stay this way? In the
current state, and to guarantee deterministic PRNG sequences, all calls
to `random_init()` *must* be ignored, but not the first. Of course, this
can be done in various ways ..
1) we can define it as BCP to *not* use `random_init()` if `auto_init`
=> it's hard to guarantee a one-time call to `random_init()` as human
do surely err (especially if several nested modules are involved).
2) check within `random_init()` for an unitialized state and only
initialize if such a state is prevalent. Ignore the call to
`random_init()` if the PRNG was initialized before.
=> this introduces a further check that is done with each call to
`random_init()` and feigns to the user a freshly initialized PRNG.
In contrast to the current procedure of having a global state, we rather
should opt to allow local states for each thread (not excluding a global
state). Although I have no special use case in mind at the moment, I
believe that it should be possible to let user applications initialize
"their own PRNG" to produce deterministic sequences. With the current
approach, the sequence of our PRNG is shared with all available threads.
This means, a user application would share the sequence with the network
stack's NDP, RPL, TCP, ... implementations.
IMO, our random API needs to be extended to provide function definitions
that also allow the passing of local seed states. However, different
PRNGs use different kind / different numbers of seeds. A "local scope"
seed struct would need to encapsulate enough information to be usable
with all PRNGs; and that's the part that deserves some thinking.
What is your opinion on having / allowing local scope seed states?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the devel