JDK-2132672 : java.util.concurrent.locks.ReentrantReadWriteLock acquisition order
  • Type: Backport
  • Backport of: JDK-6294770
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2005-12-15
  • Updated: 2011-02-16
  • Resolved: 2006-05-12
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 Availability Release.

To download the current JDK release, click here.
JDK 6
6Fixed
Description
This bug is present on both Solaris and Windows, cu env requires fixes for both.

The javadocs for java.util.concurrent.locks.ReentrantReadWriteLock say
this about acquisition order when there is a reader currently holding
the lock (the last sentance in the paragraph on Acquisition Order): In
either case, if readers are active and a writer enters the lock then no
subsequent readers will be granted the read lock until after that writer
has acquired and released the write lock.

However, my test case doesn't behave this way. What happens with a
non-fair ReentrantReadWriteLock, is that a thread gets the read lock.
Then, another thread gets enqueued to acquire the exclusive write lock.
So far so good. Now if you ask another thread to acquire the read lock,
it barges in front of the thread waiting for the write lock and acquires
a read lock.

According to the javadocs, this shouldn't have happened. The docs say
that the third thread is supposed to wait until after the write lock has
acquired and then released its write lock before this newly enqueued
reader should get to have the lock.

Comments
EVALUATION Defering this bug. We are not going to address this in tiger releases.
02-05-2006

EVALUATION This is fixed in mustang by redesigining the ReentrantReadWriteLock feature. To fix this problem in tiger also the same thing is required. The changes are very big and Risky as well. So it is adviseable to use the workaround or look for mustang.
15-12-2005

WORK AROUND Use a fair ReentrantReadWriteLock.
15-12-2005