111 * <p>The write lock provides a {@link Condition} implementation that
112 * behaves in the same way, with respect to the write lock, as the
113 * {@link Condition} implementation provided by
114 * {@link ReentrantLock#newCondition} does for {@link ReentrantLock}.
115 * This {@link Condition} can, of course, only be used with the write lock.
116 *
117 * <p>The read lock does not support a {@link Condition} and
118 * {@code readLock().newCondition()} throws
119 * {@code UnsupportedOperationException}.
120 *
121 * <li><b>Instrumentation</b>
122 * <p>This class supports methods to determine whether locks
123 * are held or contended. These methods are designed for monitoring
124 * system state, not for synchronization control.
125 * </ul>
126 *
127 * <p>Serialization of this class behaves in the same way as built-in
128 * locks: a deserialized lock is in the unlocked state, regardless of
129 * its state when serialized.
130 *
131 * <p><b>Sample usages</b>. Here is a code sketch showing how to perform
132 * lock downgrading after updating a cache (exception handling is
133 * particularly tricky when handling multiple locks in a non-nested
134 * fashion):
135 *
136 * <pre> {@code
137 * class CachedData {
138 * Object data;
139 * boolean cacheValid;
140 * final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
141 *
142 * void processCachedData() {
143 * rwl.readLock().lock();
144 * if (!cacheValid) {
145 * // Must release read lock before acquiring write lock
146 * rwl.readLock().unlock();
147 * rwl.writeLock().lock();
148 * try {
149 * // Recheck state because another thread might have
150 * // acquired write lock and changed state before we did.
151 * if (!cacheValid) {
152 * data = ...
153 * cacheValid = true;
154 * }
155 * // Downgrade by acquiring read lock before releasing write lock
156 * rwl.readLock().lock();
157 * } finally {
158 * rwl.writeLock().unlock(); // Unlock write, still hold read
159 * }
160 * }
161 *
162 * try {
163 * use(data);
164 * } finally {
165 * rwl.readLock().unlock();
166 * }
167 * }
168 * }}</pre>
169 *
170 * ReentrantReadWriteLocks can be used to improve concurrency in some
171 * uses of some kinds of Collections. This is typically worthwhile
172 * only when the collections are expected to be large, accessed by
|
111 * <p>The write lock provides a {@link Condition} implementation that
112 * behaves in the same way, with respect to the write lock, as the
113 * {@link Condition} implementation provided by
114 * {@link ReentrantLock#newCondition} does for {@link ReentrantLock}.
115 * This {@link Condition} can, of course, only be used with the write lock.
116 *
117 * <p>The read lock does not support a {@link Condition} and
118 * {@code readLock().newCondition()} throws
119 * {@code UnsupportedOperationException}.
120 *
121 * <li><b>Instrumentation</b>
122 * <p>This class supports methods to determine whether locks
123 * are held or contended. These methods are designed for monitoring
124 * system state, not for synchronization control.
125 * </ul>
126 *
127 * <p>Serialization of this class behaves in the same way as built-in
128 * locks: a deserialized lock is in the unlocked state, regardless of
129 * its state when serialized.
130 *
131 * <p><b>Sample usages.</b> Here is a code sketch showing how to perform
132 * lock downgrading after updating a cache (exception handling is
133 * particularly tricky when handling multiple locks in a non-nested
134 * fashion):
135 *
136 * <pre> {@code
137 * class CachedData {
138 * Object data;
139 * boolean cacheValid;
140 * final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
141 *
142 * void processCachedData() {
143 * rwl.readLock().lock();
144 * if (!cacheValid) {
145 * // Must release read lock before acquiring write lock
146 * rwl.readLock().unlock();
147 * rwl.writeLock().lock();
148 * try {
149 * // Recheck state because another thread might have
150 * // acquired write lock and changed state before we did.
151 * if (!cacheValid) {
152 * data = ...;
153 * cacheValid = true;
154 * }
155 * // Downgrade by acquiring read lock before releasing write lock
156 * rwl.readLock().lock();
157 * } finally {
158 * rwl.writeLock().unlock(); // Unlock write, still hold read
159 * }
160 * }
161 *
162 * try {
163 * use(data);
164 * } finally {
165 * rwl.readLock().unlock();
166 * }
167 * }
168 * }}</pre>
169 *
170 * ReentrantReadWriteLocks can be used to improve concurrency in some
171 * uses of some kinds of Collections. This is typically worthwhile
172 * only when the collections are expected to be large, accessed by
|