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

Replies are listed 'Best First'.
Re^2: Solaris + UltraSparc T2 + Threads: Avoid LCK's by BrowserUk (Patriarch) on Apr 23, 2009 at 18:04 UTC
Hmm. That doesn't make sense. You have calls to rand in both examples. The only difference being the frequency with which it is called; several thousand times more frequently in the first apparently non-locking example, than in the second apparently locking example. If rand were responsible for the locks then the first example should be the one to display the symptoms of them. Not the second. Methinks you are misinterpreting your results. 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^3: Solaris + UltraSparc T2 + Threads: Avoid LCK's by gulden (Monk) on Apr 23, 2009 at 18:19 UTC
Ok, I've cheated the test :D, didn't realize that... sorry The problem its related with the random function, whenever I use it the LOCKs appears... When I don't use it the CPU reaches the 100% Can we assume that we must avoid rand function whenever using threads?	[reply]
Re^4: Solaris + UltraSparc T2 + Threads: Avoid LCK's by BrowserUk (Patriarch) on Apr 23, 2009 at 19:25 UTC
The problem its related with the random function, whenever I use it the LOCKs appears... If that's the case, it sounds like your platform has a badly adapted rand function. I don't see any locking involved with the use of rand on my system. Can we assume that we must avoid rand function whenever using threads? That would be overkill. In any real workload, calls to rand will likely make up a mere fraction of the total workload, so any contention involved will also likely be minimal for real applications. In general, drawing conclusions based on extreme testcases--like calling rand in a tight loop concurrrently on 64-threads--is silly. If you ever comeup with a real application that suffers unduly as a result of lock contention calling rand, then consider using an alternative rand implementation. But the likelyhood of you ever encoutering this as a real problem in real code is quite small. 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^5: Solaris + UltraSparc T2 + Threads: Avoid LCK's by gulden (Monk) on Apr 24, 2009 at 10:53 UTC
Re^6: Solaris + UltraSparc T2 + Threads: Avoid LCK's by BrowserUk (Patriarch) on Apr 24, 2009 at 12:15 UTC
Some notes below your chosen depth have not been shown here
Re^2: Solaris + UltraSparc T2 + Threads: Avoid LCK's by RMGir (Prior) on Apr 24, 2009 at 11:45 UTC
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	[reply]
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]