0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 2362N/A * published by the Free Software Foundation. Oracle designates this 0N/A * particular file as subject to the "Classpath" exception as provided 2362N/A * by Oracle in the LICENSE file that accompanied this code. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 2362N/A * or visit www.oracle.com if you need additional information or have any 0N/A * This file is available under and governed by the GNU General Public 0N/A * License version 2 only, as published by the Free Software Foundation. 0N/A * However, the following notice accompanied the original version of this 0N/A * Written by Doug Lea with assistance from members of JCP JSR-166 0N/A * Expert Group and released to the public domain, as explained at 0N/A * A <tt>ReadWriteLock</tt> maintains a pair of associated {@link 0N/A * Lock locks}, one for read-only operations and one for writing. 0N/A * The {@link #readLock read lock} may be held simultaneously by 0N/A * multiple reader threads, so long as there are no writers. The 0N/A * {@link #writeLock write lock} is exclusive. 0N/A * <p>All <tt>ReadWriteLock</tt> implementations must guarantee that 0N/A * the memory synchronization effects of <tt>writeLock</tt> operations 0N/A * (as specified in the {@link Lock} interface) also hold with respect 0N/A * to the associated <tt>readLock</tt>. That is, a thread successfully 0N/A * acquiring the read lock will see all updates made upon previous 0N/A * release of the write lock. 0N/A * <p>A read-write lock allows for a greater level of concurrency in 0N/A * accessing shared data than that permitted by a mutual exclusion lock. 0N/A * It exploits the fact that while only a single thread at a time (a 0N/A * <em>writer</em> thread) can modify the shared data, in many cases any 0N/A * number of threads can concurrently read the data (hence <em>reader</em> 0N/A * In theory, the increase in concurrency permitted by the use of a read-write 0N/A * lock will lead to performance improvements over the use of a mutual 0N/A * exclusion lock. In practice this increase in concurrency will only be fully 0N/A * realized on a multi-processor, and then only if the access patterns for 0N/A * the shared data are suitable. 0N/A * <p>Whether or not a read-write lock will improve performance over the use 0N/A * of a mutual exclusion lock depends on the frequency that the data is 0N/A * read compared to being modified, the duration of the read and write 0N/A * operations, and the contention for the data - that is, the number of 0N/A * threads that will try to read or write the data at the same time. 0N/A * For example, a collection that is initially populated with data and 0N/A * thereafter infrequently modified, while being frequently searched 0N/A * (such as a directory of some kind) is an ideal candidate for the use of 0N/A * a read-write lock. However, if updates become frequent then the data 0N/A * spends most of its time being exclusively locked and there is little, if any 0N/A * increase in concurrency. Further, if the read operations are too short 0N/A * the overhead of the read-write lock implementation (which is inherently 0N/A * more complex than a mutual exclusion lock) can dominate the execution 0N/A * cost, particularly as many read-write lock implementations still serialize 0N/A * all threads through a small section of code. Ultimately, only profiling 0N/A * and measurement will establish whether the use of a read-write lock is 0N/A * suitable for your application. 0N/A * <p>Although the basic operation of a read-write lock is straight-forward, 0N/A * there are many policy decisions that an implementation must make, which 0N/A * may affect the effectiveness of the read-write lock in a given application. 0N/A * Examples of these policies include: 0N/A * <li>Determining whether to grant the read lock or the write lock, when 0N/A * both readers and writers are waiting, at the time that a writer releases 0N/A * the write lock. Writer preference is common, as writes are expected to be 0N/A * short and infrequent. Reader preference is less common as it can lead to 0N/A * lengthy delays for a write if the readers are frequent and long-lived as 0N/A * expected. Fair, or "in-order" implementations are also possible. 0N/A * <li>Determining whether readers that request the read lock while a 0N/A * reader is active and a writer is waiting, are granted the read lock. 0N/A * Preference to the reader can delay the writer indefinitely, while 0N/A * preference to the writer can reduce the potential for concurrency. 0N/A * <li>Determining whether the locks are reentrant: can a thread with the 0N/A * write lock reacquire it? Can it acquire a read lock while holding the 0N/A * write lock? Is the read lock itself reentrant? 0N/A * <li>Can the write lock be downgraded to a read lock without allowing 0N/A * an intervening writer? Can a read lock be upgraded to a write lock, 0N/A * in preference to other waiting readers or writers? 0N/A * You should consider all of these things when evaluating the suitability 0N/A * of a given implementation for your application. 0N/A * @see ReentrantReadWriteLock 0N/A * @see ReentrantLock 0N/A * Returns the lock used for reading. 0N/A * @return the lock used for reading. 0N/A * Returns the lock used for writing. 0N/A * @return the lock used for writing.