[concurrency-interest] Low cpu usage with fair ReentrantLock

Martin Buchholz martinrb at google.com
Thu May 13 02:37:23 EDT 2010

On Tue, May 11, 2010 at 01:31, Andrew Haley <aph at redhat.com> 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.

With fair locks, if lock attempts occur more often than
once per time slice, then just one contended lock
will cause throughput to drop to one lock acquisition
per time slice.


More information about the Concurrency-interest mailing list