in reply to Re: Solaris + UltraSparc T2 + Threads: Avoid LCK's
in thread Solaris + UltraSparc T2 + Threads: Avoid LCK's

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."
  • 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 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?
      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.
        I made new tests and still not understand what the real reason.

        Instead of rand I have used other expressions:

        my $line = qq|Calling-Station-Id = "#crnh-b|; for( 1 .. 7e6 ) { expr N }

        Expr 1 (LOCKs High)

        my ($key, $value) = split(/ = /, $line);

        Expr 2 (LOCKs High)

        $line =~ /^([^=]+)\s=\s(.+)$/o;

        Expr 3 (No LOCKs at all)

        my $idx = index $line, " = ", 1; my $key = substr($line, 1,$idx); my $value = substr($line,$idx + 3);
        What is wrong? my Perl, my SO? or I'm not thinking right?