[concurrency-interest] Instrumentation for locks

Doug Lea dl@cs.oswego.edu
Tue, 16 Sep 2003 06:54:41 -0400

Hi Adam,

> One feature which we've found to be quite useful in the locking classes 
> we currently use in WebLogic Server, is the ability to interrogate 
> locks/semaphores for the current/high-water-mark number of waiters and 
> wait times.  In some cases this functionality can be obtained at 
> little/no additional runtime cost.  In other cases it does have a 
> slight impact.

Thanks for the suggestion! Usually people who want lock monitoring ask
for so much of it that it really cannot and should not be supported in
an "ordinary" lock class.  But in our ReentrantLock class, it would
indeed be possible to generalize method isLocked to return an estimate
of the number of threads blocked, at no overhead cost for any other
operations. Unless we find some reason not to do it after thinking it
through some more, we will add method
getEstimatedNumberOfWaitingThreads (or some similar/better name).

In our current ReentrantLock implementation, getting a list of wait
times would not be possible, but I'll investigate to see if any simple
set of adjustments that don't otherwise impact performance could be
done here.

Similar functionality can be added to ReentrantLock.Condition,
although possibly not in such a usable/useful form. You need to hold a
lock to do anything at all with its condition; even to see if there
are any waiters. Which means that monitoring could interfere with
use. Plus, I worry a bit about the bad programming practices that
condition wait-queue inspection methods can lead to. It is almost
never correct to base any action on whether their are any waiters, yet
people might be very tempted to do this if we supply such a method.
What do you think?

Also, the ReentrantReadWriteLock class currently does not contain any
inspection methods. For uniformity, we may be able to add some
analogous methods.