fastnoise_source uses non thread-safe rand() function #1542

mgw93 · 2017-12-20T11:16:55Z

The fast noise source block uses the rand() function to sample the precalculated values.
As rand() is not thread safe, this leads to non-reproducible behaviour.
Also, the specified seed value is not used with srand.
It might be better to use the random number functions in boost or in C++11.

To easily show this behaviour, connect two fast noise sources with the same seed to a subtract block and plot the output.

Closes gnuradio#1542. Also, replaces the pool generation based on gr::random by RV generated by the same XOROSHIRO128+ RNG used to calculate the random pool indices. If it's good enough, it's good enough – and all statistical tests I can come up with so far say it is good enough.

This solves the issue with libc rand() relying on global (not thread-local!) state and thus not being suited for multithreaded applications. This fixes gnuradio#1542.

This solves the issue with libc rand() relying on global (not thread-local!) state and thus not being suited for multithreaded applications. This fixes #1542.

marcusmueller mentioned this issue Jan 27, 2018

gr::random(unsigned int seed) <-> fastnoise_source(long seed) #1559

Closed

marcusmueller mentioned this issue Jan 27, 2018

replaced thread-unsafe rand() in fastnoise_source by XOROSHIRO128+ #1562

Merged

mbr0wn added the Bug label Feb 4, 2018

marcusmueller added a commit that referenced this issue Mar 4, 2018

Converted fastnoise_source from rand() to xoroshiro128+

65217b6

This solves the issue with libc rand() relying on global (not thread-local!) state and thus not being suited for multithreaded applications. This fixes #1542.

marcusmueller closed this as completed in c31f528 Mar 30, 2018

fastnoise_source uses non thread-safe rand() function #1542

fastnoise_source uses non thread-safe rand() function #1542

Comments

mgw93 commented Dec 20, 2017