United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6207928 : ReentrantReadWriteLock provides no way to tell if current thread holds read lock

Details
Type:
Enhancement
Submit Date:
2004-12-13
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2005-09-04
Component:
core-libs
OS:
windows_xp
Sub-Component:
java.util.concurrent
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
A DESCRIPTION OF THE REQUEST :
The class java.util.ReentrantReadWriteLock  provides no way to tell if a given thread currently holds a read lock. I am looking for the equivalent of the Thread.holdsLock() method that would tell me this, so I can use it in 'assert' statements to verify that a particular method is only called in circumstances where the object is locked for reading. For instance:

private final ReentrantReadWriteLock _lock = new ReentrantReadWriteLock();
private final ReadLock _read = _lock.readLock();
private final WriteLock _write = _lock.writeLock();

void readSomething() {
      _read.lock();
      try {
            doSomething();
      }
      finally {
            _read.unlock();
      }
}
void doSomething() {
      assert _readLock.isHeldByCurrentThread(); // There is no way to do this!
      //... do something read-only here ...
}


JUSTIFICATION :
The reasons to add this feature are essentially the same as those which motivated the Thread.holdsLock() feature. This feature is extremely useful in enforcing threading constraints via 'assert' and hence reducing debugging time by detecting when a method is accidentally called without establishing a lock on any necessary objects.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -

I was surprised that the lock objects returned by  the ReentrantReadWriteLock.readLock() and reentrantReadWriteLock.writeLock()  methods do not support the ReentrantLock interface, which would have provided the isHeldByCurrentThread() method. Also, for some mysterious reason, the ReentrantReadWriteLock class provides a "isWriteLockedByCurrentThread()" method, but not a "isReadLockedByCurrentThread()".

Ideally, I would like to see ReentrantReadWriteLock return a ReentrantLock instance from its readLock() and writeLock() methods, instead of a Lock object as it does now. I would also like to see an "isReadLockedByCurrentThread()" method added  to ReentrantReadWriteLock (which would parallel the existing isWriteLockedByCurrentThread() method.)
ACTUAL -
There appears to be no way to determine if the current thread holds a read lock on a ReentrantReadWriteLock object.

---------- BEGIN SOURCE ----------
Source code examples given above.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I have not discovered any workarounds.
###@###.### 2004-12-13 23:37:57 GMT

                                    

Comments
EVALUATION

Doug Lea is providing a fix as part of a rewrite of
ReentrantReadWriteLock
                                     
2005-08-02
EVALUATION

From the docs:

 * <p>A reentrant write lock intrinsically defines an owner and can
 * only be released by the thread that acquired it.  In contrast, in
 * this implementation, the read lock has no concept of ownership, and
 * there is no requirement that the thread releasing a read lock is
 * the same as the one that acquired it.  However, this property is
 * not guaranteed to hold in future implementations of this class.
 
Therefore, the current behavior is likely intentional.
###@###.### 2004-12-14 06:24:29 GMT

Doug Lea writes:

The current design and behavior are intentional.  Read-locks are
normally not defined to have a notion of ownership, so ownership
cannot be tested.  The submitter can instead use
  assert lock.getReadLockCount() > 0;
This is weaker than a per-thread ownership test, but will usually
suffice in practice to catch errors.

The JSR166 EG has received a few requests to optionally support
per-thread read-hold tracking. Doing this would significantly increase
lock overhead, so would need to be governed by an optional
construction parameter. We are looking into it.


###@###.### 2004-12-14 16:17:57 GMT
                                     
2004-12-14



Hardware and Software, Engineered to Work Together