Re: [Boost-users] RNG

From: Michael B. Edwin Rickert (panda_at_[hidden])
Date: 2005-06-01 04:42:40

Sliwa, Przemyslaw (London) wrote:

>All,
> 
>I have a question which is not related directly to boost. 
>  
>
For future reference, from:
http://www.boost.org/more/discussion_policy.htm
It would seem that this probably belongs in a newsgroup (such as 
comp.lang.c++.moderated - I could be wrong, being new, just thought I'd 
point this out).

>I am writing a multithreaded application... [*snip*]
>My question is: making the random number generator a
>global variable (object) it is possible to use it in several threads at
>the same time -> does it mean that the random sequences will be repeated
>and the entire simulation will be simply a repetition of n non-random
>sequences?
>
This depends on the RNG used - most are not thread safe, and depending 
on the generator the same number will have a tendancy to come up repeatedly.

> This can be avoided when a lock is acquired on the random
>number generator and at a given time just one thread  can access the rng
>and the advantage of the multiprocessor machine is lost. Can you advise?
>  
>
Assuming that 100% of your time is spent getting RNGs - I don't know the 
details of the simulation you're working on... but an absolute 100% is 
impossible for anything useful (e.g. it amounts to an optimized "while( 
1 ) { rand(); }"). That said, the (un)locking overhead may offset any 
benifits, profile this to confirm this is a concern. Unless you need to 
be able to repeat a sequence for some reason, multiple RNGs (one per 
thread) with seperate seeds should work (and may even work for 
repeatable simulations, with the proper conditions). There's also 
hardware RNGs that depend on quantum physics to produce truely random 
numbers, although I don't have the links stored, which I'm sure could be 
used effectively.

Further, assuming less than 50% of your time (for a dual-processor 
system) is spent actually generating the numbers, you could have one 
thread in charge of number generation, filling up random number pools 
for each thread (and pausing when each thread has it's own pool up to 
high enough levels). Of course, such techniques should be covered in a 
good book on multithreading...

Hope this helps.

       -Mike