[concurrency-interest] Low cpu usage with fair ReentrantLock
Gregg Wonderly
gregg at cytetech.com
Wed May 12 14:54:40 EDT 2010
Andrew Haley wrote:
> On 05/10/2010 11:42 PM, David Holmes wrote:
>> Andrew Haley writes on Tuesday, 11 May 2010 2:36 AM:
>>> Perhaps so. It's hard to tell from that javadoc exactly what is
>>> meant: I thought, from reading that, that "slower; often much slower"
>>> referred to slow operation with high CPU loads when locking rather
>>> than, as we have here, CPUs being starved of work. But in any case,
>>> given the fact that locking is so rare, I found this result a little
>>> bit surprising.
>> Just one further comment. Locking may be "rare" from the perspective of
>> locked-work:unlocked-work, but it would seem that your threads are executing
>> in-phase, and so contention is actually high.
>
> So it seems. They don't start in phase, but because of the convoying
> effect they eventually move into lock-step. I wonder how often this
> happens the real world applications.
This happens anytime that an "event" is slower than other events. On slower
CPUs and systems with random delays associated with Disk I/O, network activity
and other places where randomization occurs, these types of things can be
remedied. But by and large, there is not a single multi-threaded application
which won't show this behavior in some form when mostly CPU is involved with
some form of rendezvous point that takes much longer to execute.
Think about this as you would a highway with tollgates every 5 miles. With
significant traffic through the toll gates, eventually backups start, and never
really disappear until queuing theory things kick in such that the departure
rate finally outstrips the arrival rate.
One thing you can try, is to use random "sleeps" to distribute the "position" of
the threads over the time interval between "gates". Find out what the average
time is, between gates. Then do something like
if( contendedLastLockTooLong ) {
Thread.sleep( (long)(Math.random(gateTime/numberOfThreads)+1) );
}
to make the thread back off it's position relative to the others in the
"timeline" of work through the gates.
Gregg Wonderly
More information about the Concurrency-interest
mailing list