JDK-6207928 : ReentrantReadWriteLock provides no way to tell if current thread holds read lock
  • Type: Enhancement
  • Status: Resolved
  • Resolution: Fixed
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Priority: P4
  • Affected Version: 5.0
  • OS: windows_xp
  • CPU: x86
  • Submit Date: 2004-12-13
  • Updated Date: 2010-04-02
  • Resolved Date: 2005-09-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
6 b51Resolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
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() {
      try {
      finally {
void doSomething() {
      assert _readLock.isHeldByCurrentThread(); // There is no way to do this!
      //... do something read-only here ...

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.


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

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

EVALUATION Doug Lea is providing a fix as part of a rewrite of ReentrantReadWriteLock

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