Re^2: Solaris + UltraSparc T2 + Threads: Avoid LCK's

It's not completely crazy to think that getting random numbers might involve a lock, but it's going to depend on the system, and I don't think that's what's happening on the system gulden is using.

On Solaris, my perl 5.8.8 gets random numbers by opening /dev/urandom and reading a value. I don't think that's likely to involve locks.

But one could certainly imagine a (less than ideal) pseudo-random number generator implementation that uses locks to protect shared state.

Mike

Comment on Re^2: Solaris + UltraSparc T2 + Threads: Avoid LCK's

Replies are listed 'Best First'.
Re^3: Solaris + UltraSparc T2 + Threads: Avoid LCK's by BrowserUk (Patriarch) on Apr 24, 2009 at 12:08 UTC
But one could certainly imagine a (less than ideal) pseudo-random number generator implementation that uses locks to protect shared state. I agree. What is crazy is blaming rand, when in the data he posted, the code that ran rand in tight loops on 64 threads, showed no locking symptoms, but the version that interspersed each call to rand with a 100k assignments did. A conservative test shows the former making ~700,000 calls to rand per second, the latter 105/sec. If either was going to suffer lock contention, you'd expect it to be the former. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: Solaris + UltraSparc T2 + Threads: Avoid LCK's by RMGir (Prior) on Apr 24, 2009 at 13:10 UTC
Agreed. The other findings later in the thread rule out rand anyhow. Mike	[reply]