I'm not sure if any of this is helpful as I'm on a different platform and I'm not at all sure that anything I'm seeing will be applicable. When I run this version of your code here:

#! perl -sw
use 5.010;
use strict;
use threads;

$_->join for map {
    async {
        for( 1 .. 7e6 ) {
            int rand 10;
        }
    };
} 1 .. 64;

say "Test 1 complete"; <STDIN>;

$_->join for map {
    async {
        my $tmp;
        for ( 1 .. 7e6 ) {
            for ( 1 .. 1e5 ) {
                $tmp = $_;
            }
            int rand 10;
        }
    };
} 1 .. 64;
[download]

I do perceive a very slight drop in cpu sctivity between the first batch and the second.

The first nails the cpu counter at (or very close to) 75% (100% of 3 of 4 cpus--I have something running on the other cpu). What minor wobbles occur go no lower than 74.8; and it occasionally shows slightly greater than 75%--though that probably just the result of maths.

The second again gets close to 75%, but the wobbles are larger. It occasionally drops as far as 73% and rarely get as high as 74.8%. So something is preventing the second from maxing the cpu. I do not see any signs of locks, though I may not be instrumenting the right things. I need to look further into the measurements available--the list is very long. But in any case, the drop is nothing like as dramatic here, as your instrumentation appears to show on your platform!

Following anonymonks lead, I replaced (both) implicit loop counters with lexicals in the second batch:

        for my $i ( 1 .. 7e6 ) {
            for my $j ( 1 .. 1e5 ) {
                $tmp = $j;
            }
[download]

And the drop in cpu utilization "went away", which does tend to indicate that it is somehow related to use of the global $_. Whilst that is global, it isn't shared, (I bleieve it is cloned on a per interpreter basis), so it shouldn't require internal locking. But globals do carry a small penalty over lexicals--regardless of the use of threads--so whether that has anything to do with it I am unsure. I can't see why it would, but I have considerable difficulty follwing the internals in areas that relate to cloning.

I'll try too look into it in more detail, but that will take a while.

I've done plenty of multi-threaded code in C++, but never in Perl, so take this with a grain of salt.

I suspect that RMGir is right: Since $tmp seems to be shared amongst all the threads, perl may be wrapping reads/writes to it with a mutex, and you may just have a lot of mutex lock contentions on it. If I understand perl well enough (and I likely don't), then I suspect that moving the my $tmp into the body of the first for loop may resolve the problem: that way, each thread should(?) have it's own copy of $tmp.

I don't have a sufficiently recent threaded perl build around to test this theory, but I'd look at that assignment to $tmp in the inner loop in test2.

What happens if you just copy the int(rand(10)) into the inner loop without an assignment?

Of course, if this turns out to be the answer, WHY an assignment to a thread-local variable would cause that is a different question...

for (1..7235617){
    for my $i (1..100000){    
       $tmp = $_;
    }
}
[download]

The LOCKS are not in the inner loop!!! The same behaviour when i put your code in Test1...

The solution for this is the less important, the motives for that, its what I want?

This must be related to the way the rand function is implemented ....

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."

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?

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

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."