On Fri, Aug 21, 2009 at 17:48, Sturla Molden<stu...@molden.no> wrote: > > I am not sure if this is the right place to discuss this issue. However, > I problem I keep running into in Monte Carlo simulations is generating > pseudorandom numbers with multiple threads. PRNGs such as the Mersenne > Twister keep an internal state, which prevents the PRNG from being > re-entrant and thread-safe.
C extension function calls are always atomic unless if they release the GIL. numpy.random does not. You have de facto locks thanks to the GIL. > Possible solutions: > > > 1. Use multiple instances of PRNG states (numpy.random.RandomState), one > for each thread. This should give no contention, but is this > mathematically acceptable? I don't know. At least I have not seen any > proof that it is. As long as you use different seeds, I believe this is fine. The state size of MT is so enormous that almost any reasonable use will not find overlaps. Although you don't really have re-entrancy issues, you will usually want one PRNG per thread for determinism. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
