Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net