3 ms·
I think the point is that the library probably should assume that if you called `Rand.seed` and/or `srand` it's because you intended to get a specific sequence
by yuliyp 2y ago
I think the point is that the library probably should assume that if you called `Rand.seed` and/or `srand` it's because you intended to get a specific sequence of random numbers out of it.
- vlovich123 2y agoWhat did I write that suggests you wouldn’t get a deterministic specific sequence equivalent to a lock within the RNG? What I said is if you fail to synchronize the surrounding code’s order of calls into the RNG, then you’re going to have non-determinism anyway even with locks within the RNG. For example: T1: If rng() < 0.5 { Rng() } T2: Rng() The specific numbers returned by calls to rng() depend on the thread ordering UNLESS the user carefully has higher level synchronization themselves to guarantee the ordering. This shows that the locking within the RNG is insufficient and the better performing option that maintains equivalent invariants should be selected (i.e. initialize the TLS RNG state for the new thread from a call to read entropy from the current thread’s RNG state).
- yuliyp 2y agoI'm trying to figure out how you switch "into" thread-local prng mode after a call to srand. Case 1: T1: srand(); rng(); rng() T2: no calls to rng Case 2: T1: srand(); T2: (spawns after the srand call) rng(); rng() How would T2 know that it should produce the seeded sequence as opposed to one based on its own prng?
- vlovich123 2y agosrand sets a TLS flag and the thread spawning code checks that flag on-thread to know how to initialize the off-thread rng).