United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6294770 java.util.concurrent.locks.ReentrantReadWriteLock acquisition order
JDK-6294770 : java.util.concurrent.locks.ReentrantReadWriteLock acquisition order

Details
Type:
Bug
Submit Date:
2005-07-07
Status:
Resolved
Updated Date:
2010-05-08
Project Name:
JDK
Resolved Date:
2005-09-04
Component:
core-libs
OS:
windows_xp
Sub-Component:
java.util.concurrent
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u4
Fixed Versions:

Related Reports
Backport:
Relates:
Relates:
Relates:

Sub Tasks

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.
###@###.### 2005-07-07 22:38:59 GMT

                                    

Comments
WORK AROUND

Use a fair ReentrantReadWriteLock.
###@###.### 2005-07-07 22:39:00 GMT
                                     
2005-07-07
EVALUATION

This is being addressed by a rework of 
ReentrantReadWriteLock
by Doug Lea and the JSR-166 expert group alumni.
                                     
2005-08-02



Hardware and Software, Engineered to Work Together