java.util.concurrent.locks
Class ReentrantReadWriteLock

java.lang.Object
  java.util.concurrent.locks.ReentrantReadWriteLock

All Implemented Interfaces:

ReadWriteLock, Serializable

public class ReentrantReadWriteLock

extends Object

implements ReadWriteLock, Serializable

An implementation of ReadWriteLock supporting similar semantics to ReentrantLock.

This class has the following properties:

• Acquisition order

  This class does not impose a reader or writer preference ordering for lock access. However, it does support an optional fairness policy. When constructed as fair, threads contend for entry using an approximately arrival-order policy. When the write lock is released either the longest-waiting single writer will be assigned the write lock, or if there is a reader waiting longer than any writer, the set of readers will be assigned the read lock. When constructed as non-fair, the order of entry to the lock need not be in arrival 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.

• Reentrancy

  This lock allows both readers and writers to reacquire read or write locks in the style of a ReentrantLock. Readers are not allowed until all write locks held by the writing thread have been released.

  Additionally, a writer can acquire the read lock - but not vice-versa. Among other applications, reentrancy can be useful when write locks are held during calls or callbacks to methods that perform reads under read locks. If a reader tries to acquire the write lock it will never succeed.

• Lock downgrading

  Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock, is not possible.

• Interruption of lock acquisition

  The read lock and write lock both support interruption during lock acquisition. And both view the interruptible lock methods as explicit interruption points and give preference to responding to the interrupt over normal or reentrant acquisition of the lock, or over reporting the elapse of the waiting time, as applicable.

• Condition support

  The write lock provides a Condition implementation that behaves in the same way, with respect to the write lock, as the Condition implementation provided by ReentrantLock.newCondition() does for ReentrantLock. This Condition can, of course, only be used with the write lock.

  The read lock does not support a Condition and readLock().newCondition() throws UnsupportedOperationException.

Sample usage. Here is a code sketch showing how to exploit reentrancy to perform lock downgrading after updating a cache (exception handling is elided for simplicity):

 class CachedData {
   Object data;
   volatile boolean cacheValid;
   ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

   void processCachedData() {
     rwl.readLock().lock();
     if (!cacheValid) {
        // upgrade lock manually
        rwl.readLock().unlock();   // must unlock first to obtain writelock
        rwl.writeLock().lock();
        if (!cacheValid) { // recheck
          data = ...
          cacheValid = true;
        }
        // downgrade lock
        rwl.readLock().lock();  // reacquire read without giving up write lock
        rwl.writeLock().unlock(); // unlock write, still hold read
     }

     use(data);
     rwl.readLock().unlock();
   }
 }
 

Implementation Considerations

In addition to the above, this reference implementation has the following property:

• Ownership

  While not exposing a means to query the owner, the write lock does internally define an owner and so the write lock can only be released by the thread that acquired it.

  In contrast, the read lock has no concept of ownership. Consequently, while not a particularly good practice, it is possible to acquire a read lock in one thread, and release it in another. This can occasionally be useful.

Since:

1.5

See Also:

Serialized Form

ReentrantReadWriteLock

public ReentrantReadWriteLock()

Creates a new ReentrantReadWriteLock with default ordering properties.

ReentrantReadWriteLock

public ReentrantReadWriteLock(boolean fair)

Creates a new ReentrantReadWriteLock with the given fairness policy.

Parameters:

fair - true if this lock should use a fair ordering policy

writeLock

public Lock writeLock()

Description copied from interface: ReadWriteLock

Return the lock used for writing.

Specified by:

writeLock in interface ReadWriteLock

readLock

public Lock readLock()

Description copied from interface: ReadWriteLock

Return the lock used for reading.

Specified by:

readLock in interface ReadWriteLock

isFair

public boolean isFair()

Return true if this lock has fairness set true.

Returns:

true if this lock has fairness set true.

getReadLocks

public int getReadLocks()

Queries the number of read locks held for this lock. This method is designed for use in monitoring of the system state, not for synchronization control.

Returns:

the number of read locks held.

isWriteLocked

public boolean isWriteLocked()

Queries if the write lock is held by any thread. This method is designed for use in monitoring of the system state, not for synchronization control.

Returns:

true if any thread holds write lock and false otherwise.

isWriteLockedByCurrentThread

public boolean isWriteLockedByCurrentThread()

Queries if the write lock is held by the current thread.

Returns:

true if current thread holds this lock and false otherwise.

getWriteHoldCount

public int getWriteHoldCount()

Queries the number of reentrant write holds on this lock by the current thread.

A writer thread has a hold on a lock for each lock action that is not matched by an unlock action.

Returns:

the number of holds on this lock by the current thread, or zero if this lock is not held by the current thread.

getQueueLength

public int getQueueLength()

Returns an estimate of the number of threads waiting to acquire this lock. The value is only an estimate because the number of threads may change dynamically while this method traverses internal data structures. This method is designed for use in monitoring of the system state, not for synchronization control.

Returns:

the estimated number of threads waiting for this lock

getWriter

protected Thread getWriter()

Returns the thread that currently owns the write lock, or null if not owned. Note that the owner may be momentarily null even if there are threads trying to acquire the lock but have not yet done so. This method is designed to facilitate construction of subclasses that provide more extensive lock monitoring facilities.

Returns:

the owner, or null if not owned.

getQueuedThreads

protected Collection<Thread> getQueuedThreads()

Returns a collection containing threads that may be waiting to acquire this lock. Because the actual set of threads may change dynamically while constructing this result, the returned collection is only a best-effort estimate. The elements of the returned collection are in no particular order. This method is designed to facilitate construction of subclasses that provide more extensive lock monitoring facilities.

Returns:

the collection of threads

getQueuedWriterThreads

protected Collection<Thread> getQueuedWriterThreads()

Returns a collection containing threads that may be waiting to acquire the write lock. Because the actual set of threads may change dynamically while constructing this result, the returned collection is only a best-effort estimate. The elements of the returned collection are in no particular order. This method is designed to facilitate construction of subclasses that provide more extensive lock monitoring facilities.

Returns:

the collection of threads

getQueuedReaderThreads

protected Collection<Thread> getQueuedReaderThreads()

Returns a collection containing threads that may be waiting to acquire the read lock. Because the actual set of threads may change dynamically while constructing this result, the returned collection is only a best-effort estimate. The elements of the returned collection are in no particular order. This method is designed to facilitate construction of subclasses that provide more extensive lock monitoring facilities.

Returns:

the collection of threads