问题
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?
回答1:
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.
回答2:
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
回答3:
It will generally make them less deterministic (bad if you rely upon their determinism, which many people do), and may or may not make them less pseudo-random, depending upon their particular implementation details and the subtleties of how your hardware behaves.
But typically people writing multithreaded apps declare their PRNG state in TLS (thread-local-storage). This way it doesn't matter, every thread has their own PRNG, and races won't happen unless you deliberately create them. Not inside the PRNG code anyway. This is lock-free and more or less full performance (depending upon TLS implementation used).
来源：https://stackoverflow.com/questions/616434/do-prng-need-to-be-thread-safe