For issues of memory and simplicity, I'd like to share random number stream harvests among threads. I don't care if, occasionally, a thread gets the 'wrong' or same random number as another thread because the index has not been bumped yet. That is, the threads would share the index into the stream and the stream. When any thread noticed the index becoming close to the end of the stream, it would invoke a continuation of the stream.
My attempts to implement this have the program blowing off w/ no diagnostics or references to irrelevant lines of code. Could it be that the VSL routines save data which becomes corrupted if there are multiple threads accessing the code simultaneously? Wouldn't this also be a problem if I gave up on this approach and set the indicies private?
>>I don't care if, occasionally, a thread gets the 'wrong' or same random number as another thread because the index has not been bumped yet.
I assume you want performance. Asume also it is not important for the end of life of use of a random number by a specific thread be the same sequence as the beginning of life of use of a random number.
Then have each thread use their own random number generator who's initial seed is dependent upon thread number or thread ID in a manner such that collisions initially at large intervals (or not at all).
Thanks for your thoughts.
Sergey: I use lots of random numbers throughout the code. If I have to stop everyone for each call, it would be hopeless. Note that the Fortran RAN intrinsic works fine, however the low quality of the sequence kills the convergence after a few hours.
Jim: I'm not sure I exactly understand "not important for the end of life of use of a random number by a specific thread be the same sequence as the beginning of life of use of a random number." I have thought of using different random number generators (well, same generator, different seeds) and I'm getting close to trying that. There are some reasons to try the shared stream approach and I'm not sure why that doesn't seem to work. It seems that the threads should be able to share the stream...but perhaps not. ANd yes, it is ALL about performance...this code takes days to run and we're about to expand its range significantly.
thanks again, Bruce
Yes, I did seem to have some out of bounds problems but I think I cleared them up before I started this thread. I'm going ot give it one more try and then fall back to making everything private and see if that works easily.