[Boost-users] thread-safe boost::random_device / boost:mt19937

[Philipp Kraus]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Heiko Bauke]

Dear Philipp,

On Thu, 20 Dec 2012 17:26:41 +0100
Philipp Kraus <philip...@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

[Brian Budge]

On Thu, Dec 20, 2012 at 8:26 AM, Philipp Kraus
<philip...@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

[Philipp Kraus]

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

[Brian Budge]

On Thu, Dec 27, 2012 at 6:25 AM, Philipp Kraus
<philip...@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