random numbers, threads and reproducibility

[Courageous]

On Sat, 19 May 2001 14:41:54 +0700, "Neil" <mac4-devnull at theory.org> wrote:

>Requiring a threaded program to be 100% reproducable is a tall order.
>There are a lot of factors involved.  If your program simply requires that
>each thread gets the same 'random' number sequence, then I would 
>implement this by giving each thread its own whrandom instance, which
> is what you sugest below :-)

This won't help. Interactions between preemptively-multitasking threads
cannot be predicted because each thread can be subject to influences
outside of the scope of the entire program _asymmetrically_, thus making
the overall outcome non-deterministic. The play between the threads and
other programs on the machine in essence becomes a sort of random
number source in the program; the different results you see in situations
like this can be subtle: changes in ordering, differing outcomes in
resource-contention, thread syncronization unpredictability, and so forth.

On multiple cpu machines, the typical solution that modelers use to take
advantage of many cpus is "batch-run monte carlo simulation," where
multiple instances of the simulation are run on each cpu. While indeed
no one program runs any faster due to the multiple cpus, the aggregate
completes more quickly, allowing a higher rate of data collection.


C//