Java Doc for ReentrantReadWriteLock.java in  » Apache-Harmony-Java-SE » java-package » java » util » concurrent » locks » Java Source Code / Java DocumentationJava Source Code and Java Documentation

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.

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

• Instrumentation

  This class supports methods to determine whether locks are held or contended. These methods are designed for monitoring system state, not for synchronization control.

Serialization of this class behaves in the same way as built-in locks: a deserialized lock is in the unlocked state, regardless of its state when serialized.

Sample usages. 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();
 }
 }
 

 class RWDictionary {
 private final Map<String, Data>  m = new TreeMap<String, Data>();
 private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
 private final Lock r = rwl.readLock();
 private final Lock w = rwl.writeLock();
 public Data get(String key) {
 r.lock(); try { return m.get(key); } finally { r.unlock(); }
 }
 public String[] allKeys() {
 r.lock(); try { return m.keySet().toArray(); } finally { r.unlock(); }
 }
 public Data put(String key, Data value) {
 w.lock(); try { return m.put(key, value); } finally { w.unlock(); }
 }
 public void clear() {
 w.lock(); try { m.clear(); } finally { w.unlock(); }
 }
 }
 

Implementation Notes

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.

This lock supports a maximum of 65536 recursive write locks and 65536 read locks. Attempts to exceed these limits result in Error throws from locking methods.
since:
   1.5
author:
   Doug Lea