[riot-devel] To global seed or not to global seed

Cenk Gündoğan list-riot at cgundogan.de
Wed Mar 8 10:06:17 CET 2017


Heyho,

On 17-03-08 09:09:34, Kaspar Schleiser wrote:
> Hey,
> 
> On 03/08/2017 12:18 AM, Cenk Gündoğan wrote:
> > we rather
> > should opt to allow local states for each thread (not excluding a global
> > state).
> 
> Interesting. Up to now our trouble with RNGs was mostly on how to make
> them more random. Now we're trying to make them predictable. What's your
> use case for that?
> 

Well .. PRNGs are predictable with enough knowledge (algorithm used +
seed) and an enthusiastic observer (or someone who reached divine
omniscience) can even derive numbers by looking at the sequence across
several runs and constant seeds. The trouble, IMO, is seeding those
PRNGS randomly, but that's not what I wanted to focus on in this mail.
Sorry, if I gave this kind of impression.

My point is: a user application may need a specific seed to have a
deterministic sequence (especially interesting for simulation/testing).
And such determinism is removed from the application's POV, if NDP, RPL,
or TCP are also advancing the pointer in the sequence.

> How about an interface a la
> 
> rand_init_<RNGname>(rnd_<RNGname>_t *rnd);
> rand_seed32(rnd_t *rnd, uint32_t);
> rand_seed(rnd_t *rnd, const uint8_t *in, size_t len);
> rand_get(rnd_t *rnd, uint8_t *out, size_t n);
> rand_get32(rnd_t *rnd);
> 
> typedef struct {
> 	<seed, get function pointer>
> } rnd_t;
> 
> typedef struct {
> 	rnd_t rnd;
> 	<tinymt32-state>;
> } rnd_tinymt32_t;
> 
> That way we'd have:
> 
> - user controlled state
> - the ability to overload (e.g., combine hwrng, collected entropy, prng
> but with the same interface)

Looks good at first sight. We also would need some sort of
synchronization for concurrent access, e.g. a mutex in the `rnd_t`
struct, if two threads should use the same local state.

Cheerio!
Cenk

> 
> Kaspar
> 




> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20170308/5485e1a6/attachment.sig>


More information about the devel mailing list