edu.emory.mathcs.backport.java.util.concurrent.locks
public class ReentrantReadWriteLock extends Object implements ReadWriteLock, Serializable
This class has the following properties:
The order of entry to the read and write lock is unspecified, subject to reentrancy constraints. A nonfair lock that is continously contended may indefinitely postpone one or more reader or writer threads, but will normally have higher throughput than a fair lock.
DEPARTURE FROM java.util.concurrent: this implementation impose a writer-preferrence and thus its acquisition order may be different than in java.util.concurrent.
This lock allows both readers and writers to reacquire read or write locks in the style of a ReentrantLock. Non-reentrant 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.
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.
The read lock and write lock both support interruption during lock acquisition.
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 does for ReentrantLock. This Condition can, of course, only be used with the write lock.
The read lock does not support a Condition and {@code readLock().newCondition()} throws {@code UnsupportedOperationException}.
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) { // Must release read lock before acquiring write lock rwl.readLock().unlock(); rwl.writeLock().lock(); // Recheck state because another thread might have acquired // write lock and changed state before we did. if (!cacheValid) { data = ... cacheValid = true; } // Downgrade by acquiring read lock before releasing write lock rwl.readLock().lock(); rwl.writeLock().unlock(); // Unlock write, still hold read } use(data); rwl.readLock().unlock(); } }ReentrantReadWriteLocks can be used to improve concurrency in some uses of some kinds of Collections. This is typically worthwhile only when the collections are expected to be large, accessed by more reader threads than writer threads, and entail operations with overhead that outweighs synchronization overhead. For example, here is a class using a TreeMap that is expected to be large and concurrently accessed.
{@code class RWDictionary { private final Mapm = new TreeMap (); 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(); } } }}
This lock supports a maximum of 65535 recursive write locks and 65535 read locks. Attempts to exceed these limits result in Error throws from locking methods.
Since: 1.5
Nested Class Summary | |
---|---|
static class | ReentrantReadWriteLock.ReadLock
The lock returned by method ReentrantReadWriteLock. |
static class | ReentrantReadWriteLock.WriteLock
The lock returned by method ReentrantReadWriteLock. |
Constructor Summary | |
---|---|
ReentrantReadWriteLock()
Creates a new {@code ReentrantReadWriteLock} with
default (nonfair) ordering properties. |
Method Summary | |
---|---|
protected Thread | getOwner()
Returns the thread that currently owns the write lock, or
{@code null} if not owned. |
int | getQueueLength()
Returns an estimate of the number of threads waiting to acquire
either the read or write lock. |
int | getReadHoldCount()
Queries the number of reentrant read holds on this lock by the
current thread. |
int | getReadLockCount()
Queries the number of read locks held for this lock. |
int | getWriteHoldCount()
Queries the number of reentrant write holds on this lock by the
current thread. |
boolean | hasQueuedThreads()
Queries whether any threads are waiting to acquire the read or
write lock. |
boolean | isFair()
Returns {@code true} if this lock has fairness set true.
|
boolean | isWriteLocked()
Queries if the write lock is held by any thread. |
boolean | isWriteLockedByCurrentThread()
Queries if the write lock is held by the current thread.
|
Lock | readLock() |
String | toString()
Returns a string identifying this lock, as well as its lock state.
|
Lock | writeLock() |
Returns: the owner, or {@code null} if not owned
Returns: the estimated number of threads waiting for this lock
Returns: the number of holds on the read lock by the current thread, or zero if the read lock is not held by the current thread
Since: 1.6
Returns: the number of read locks held.
Returns: the number of holds on the write lock by the current thread, or zero if the write lock is not held by the current thread
Returns: {@code true} if there may be other threads waiting to acquire the lock
Returns: {@code true} if this lock has fairness set true
Returns: {@code true} if any thread holds the write lock and {@code false} otherwise
Returns: {@code true} if the current thread holds the write lock and {@code false} otherwise
Returns: a string identifying this lock, as well as its lock state