thread-safe boost::random_device / boost:mt19937
Hello, I'm using boost::random_device & boost::mt19937 for creating random numbers. I would like to use both within different threads, are both object thread-safe, so I can use it without any thread locking? Thanks Phil
Dear Philipp, On Thu, 20 Dec 2012 17:26:41 +0100 Philipp Kraus <philipp.kraus@flashpixx.de> wrote:
I'm using boost::random_device & boost::mt19937 for creating random numbers. I would like to use both within different threads, are both object thread-safe, so I can use it without any thread locking?
I am not sure if boost random number generators are thread save. In doubt, you may consider to switch to TRNG, see http://numbercrunch.de/trng/ . Heiko -- -- Number Crunch Blog @ http://numbercrunch.de -- Cluster Computing @ http://www.clustercomputing.de -- Heiko Bauke @ http://www.mpi-hd.mpg.de/personalhomes/bauke
On Thu, Dec 20, 2012 at 8:26 AM, Philipp Kraus <philipp.kraus@flashpixx.de> wrote:
Hello,
I'm using boost::random_device & boost::mt19937 for creating random numbers. I would like to use both within different threads, are both object thread-safe, so I can use it without any thread locking?
Thanks
Phil
I doubt they are thread safe due to the performance overhead involved in making them thread safe. Having written and used other MT-based RNGs, it could probably double the cost of generating random numbers, even in cases where thread safety is not required. If possible, can you construct an object per thread? This is typically the way that I have used these wrappers (and actually the reason for writing them). If you need a specific sequence, it might make sense to generate many random numbers up-front, and then use them in the thread. If all else fails, you can use your own boost::mutex and boost::lock_guard to ensure thread safety. Brian
On 2012-12-24 18:20:06 +0100, Brian Budge said:
On Thu, Dec 20, 2012 at 8:26 AM, Philipp Kraus
If possible, can you construct an object per thread?
I don't know, because I call the Boost random calls from a Lua script and initialize the boost random object with a static member globally over all threads (and MPI cores).
This is typically the way that I have used these wrappers (and actually the reason for writing them). If you need a specific sequence, it might make sense to generate many random numbers up-front, and then use them in the thread. If all else fails, you can use your own boost::mutex and boost::lock_guard to ensure thread safety.
At the moment I think a own object on each thread is a good choice, but I must change same design structures, so a mutex is a faster way to solve it Phil
On Thu, Dec 27, 2012 at 6:25 AM, Philipp Kraus <philipp.kraus@flashpixx.de> wrote:
On 2012-12-24 18:20:06 +0100, Brian Budge said:
On Thu, Dec 20, 2012 at 8:26 AM, Philipp Kraus
If possible, can you construct an object per thread?
I don't know, because I call the Boost random calls from a Lua script and initialize the boost random object with a static member globally over all threads (and MPI cores).
This is typically the way that I have used these wrappers (and actually the reason for writing them). If you need a specific sequence, it might make sense to generate many random numbers up-front, and then use them in the thread. If all else fails, you can use your own boost::mutex and boost::lock_guard to ensure thread safety.
At the moment I think a own object on each thread is a good choice, but I must change same design structures, so a mutex is a faster way to solve it
The mutex will solve the problem in about 2 minutes; however, you should be aware that if the threads are generating very many random values, this may quickly degrade performance (you might get worse performance than with a single thread). One possible workaround would be to use a thread local variable for the RNG. boost.thread also provides these via (I believe) thread_specific_ptr. Although it will still decrease performance a little, it should scale much better with the number of threads. You just have to ensure that each RNG is seeded differently. Brian
participants (3)
-
Brian Budge -
Heiko Bauke -
Philipp Kraus