Do PRNG need to be thread safe?

views:

230

answers:

+2 Q:

Do PRNG need to be thread safe?

As long as concurrent calls don't cause seg-v's or return the same value, what reasons are there for preventing race conditions and data corruption in PRNGs when those error's primary effects are unpredictable results and that is the point of a PRNG?

Edit: are there any PRNG that wouldn't suffer under race conditions and data corruption?

+2 A:

PRNGs are meticulously constructed tools -- frankly, if race conditions and threading bugs were a good PRNG, the implementation would be written that way.

The problem with adding threading bugs to increase randomness is that it's an unstudied change to the generator. Existing secure algorithms and implementations have been exhaustively tested; if you want to try an unsafe variant, you'll need to do the statistical grunt work to show that it's at least as random as a normal PRNG.

ojrac 2009-03-05 21:32:10

I'm not referring to intentionally adding threading bugs, but not going out of your way to avoid them.

BCS 2009-03-05 22:12:07

Fair enough -- but the effect will be the same if a bug sneaks in edgeways. ;) If you have the option of wrapping a static synchronized class around the PRNG's calls, that could be easiest. I really doubt a good PRNG could be constructed with a step operation small enough to be atomic.

ojrac 2009-03-05 23:31:20

You wouldn't be able to create a PRNG with a step operation that IS atomic, but you could fairly easily create one that APPEARS to be atomic, thus avoiding the costly thread locking calls. I would give an example, but PRNGs can vary too much to actually give a general example, it's a tricky thing to get lock free code going, if you already understand it, then it shouldn't be too hard to work out an implementation yourself, otherwise there is a lot of learning and trial and error before you get the hang of it and can apply one concept to a completely different algorithm

Grant Peters 2009-08-12 13:08:31

I think we're talking about different things entirely. Race conditions are a bug, even in a program to produce random output. If you want to create nondeterministic output, use a geiger counter, or something.

ojrac 2009-08-12 15:04:41

Yes, race conditions are a bug, but "wrapping a static synchronized class around the PRNG's calls" will cause massive speed issues, I was just saying that you could avoid race conditions via lock-free methods rather than relatively slow synchronization primitives

Grant Peters 2009-08-15 11:45:40

In that case, totally.

ojrac 2009-08-17 03:52:08

+4 A:

when those error's primary effects are unpredictable results and that is the point of a PRNG?

"Random" is not the same as unpredictable - Random implies a certain distribution that is very important to maintain should you want real random numbers. If your random numbers are predictable in any way it can be a security issue, or at least a program bug

Paul Betts 2009-03-05 21:42:24

ansaurus

tags:

views:

answers:

Do PRNG need to be thread safe?

related questions