On Mit, 2017-03-08 at 09:09 +0100, 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
>
Hi Oleg, Ludwig,
On 08.03.2017 10:30, Oleg Hahm wrote:
Hi Ludwig!
On Wed, Mar 08, 2017 at 10:28:13AM +0100, Ludwig Knüpfer wrote:
Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm :
Is testing and simulation the only use case you can imagine? I'm somewhat
reluctant to add
Hi Ludwig!
On Wed, Mar 08, 2017 at 10:28:13AM +0100, Ludwig Knüpfer wrote:
> Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm :
> >Is testing and simulation the only use case you can imagine? I'm somewhat
> >reluctant to add code just for non-production purposes.
>
> Since we
Hi,
Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm :
>Is testing and simulation the only use case you can imagine? I'm
>somewhat
>reluctant to add code just for non-production purposes.
Since we outspokenly target researchers with RIOT this is a production feature.
However
Hi,
Am 8. März 2017 10:06:17 MEZ schrieb "Cenk Gündoğan" :
>On 17-03-08 09:09:34, Kaspar Schleiser wrote:
>> That way we'd have:
>>
>> - user controlled state
>> - the ability to overload (e.g., combine hwrng, collected entropy,
>prng
>> but with the same interface)
>
Dear Cenk,
thanks for bringing up this discussion.
On Wed, Mar 08, 2017 at 12:18:28AM +0100, Cenk Gündoğan wrote:
> 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
Hey,
On 03/08/2017 10:06 AM, Cenk Gündoğan wrote:
>
>> How about an interface a la
>>
> 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.
Do we need that kind
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
Hey,
oh sure, here it follows:
```
The ISO C standard rand() and srand() functions allow per-process
pseudo-random streams shared by all threads. Those two functions need
not change, but there has to be mutual-exclusion that prevents
interference between two threads concurrently accessing the