Hi Cenk, thanks for bringing this up!
Can you add the POSIX perspective to the rand* calls? I guess it would be beneficial to remain close to what POSIX describes for an API.
Cheers, Thomas On 08.03.2017 00:18, Cenk Gündoğan wrote:
Dear RIOTers, 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` is used => 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? Cheers, Cenk
-- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
