| /* |
| * Written by Doug Lea with assistance from members of JCP JSR-166 |
| * Expert Group and released to the public domain, as explained at |
| * http://creativecommons.org/licenses/publicdomain |
| */ |
| |
| package java.util.concurrent.locks; |
| |
| /** |
| * A <tt>ReadWriteLock</tt> maintains a pair of associated {@link |
| * Lock locks}, one for read-only operations and one for writing. |
| * The {@link #readLock read lock} may be held simultaneously by |
| * multiple reader threads, so long as there are no writers. The |
| * {@link #writeLock write lock} is exclusive. |
| * |
| * <p>All <tt>ReadWriteLock</tt> implementations must guarantee that |
| * the memory synchronization effects of <tt>writeLock</tt> operations |
| * (as specified in the {@link Lock} interface) also hold with respect |
| * to the associated <tt>readLock</tt>. That is, a thread successfully |
| * acquiring the read lock will see all updates made upon previous |
| * release of the write lock. |
| * |
| * <p>A read-write lock allows for a greater level of concurrency in |
| * accessing shared data than that permitted by a mutual exclusion lock. |
| * It exploits the fact that while only a single thread at a time (a |
| * <em>writer</em> thread) can modify the shared data, in many cases any |
| * number of threads can concurrently read the data (hence <em>reader</em> |
| * threads). |
| * In theory, the increase in concurrency permitted by the use of a read-write |
| * lock will lead to performance improvements over the use of a mutual |
| * exclusion lock. In practice this increase in concurrency will only be fully |
| * realized on a multi-processor, and then only if the access patterns for |
| * the shared data are suitable. |
| * |
| * <p>Whether or not a read-write lock will improve performance over the use |
| * of a mutual exclusion lock depends on the frequency that the data is |
| * read compared to being modified, the duration of the read and write |
| * operations, and the contention for the data - that is, the number of |
| * threads that will try to read or write the data at the same time. |
| * For example, a collection that is initially populated with data and |
| * thereafter infrequently modified, while being frequently searched |
| * (such as a directory of some kind) is an ideal candidate for the use of |
| * a read-write lock. However, if updates become frequent then the data |
| * spends most of its time being exclusively locked and there is little, if any |
| * increase in concurrency. Further, if the read operations are too short |
| * the overhead of the read-write lock implementation (which is inherently |
| * more complex than a mutual exclusion lock) can dominate the execution |
| * cost, particularly as many read-write lock implementations still serialize |
| * all threads through a small section of code. Ultimately, only profiling |
| * and measurement will establish whether the use of a read-write lock is |
| * suitable for your application. |
| * |
| * |
| * <p>Although the basic operation of a read-write lock is straight-forward, |
| * there are many policy decisions that an implementation must make, which |
| * may affect the effectiveness of the read-write lock in a given application. |
| * Examples of these policies include: |
| * <ul> |
| * <li>Determining whether to grant the read lock or the write lock, when |
| * both readers and writers are waiting, at the time that a writer releases |
| * the write lock. Writer preference is common, as writes are expected to be |
| * short and infrequent. Reader preference is less common as it can lead to |
| * lengthy delays for a write if the readers are frequent and long-lived as |
| * expected. Fair, or "in-order" implementations are also possible. |
| * |
| * <li>Determining whether readers that request the read lock while a |
| * reader is active and a writer is waiting, are granted the read lock. |
| * Preference to the reader can delay the writer indefinitely, while |
| * preference to the writer can reduce the potential for concurrency. |
| * |
| * <li>Determining whether the locks are reentrant: can a thread with the |
| * write lock reacquire it? Can it acquire a read lock while holding the |
| * write lock? Is the read lock itself reentrant? |
| * |
| * <li>Can the write lock be downgraded to a read lock without allowing |
| * an intervening writer? Can a read lock be upgraded to a write lock, |
| * in preference to other waiting readers or writers? |
| * |
| * </ul> |
| * You should consider all of these things when evaluating the suitability |
| * of a given implementation for your application. |
| * |
| * @see ReentrantReadWriteLock |
| * @see Lock |
| * @see ReentrantLock |
| * |
| * @since 1.5 |
| * @author Doug Lea |
| */ |
| public interface ReadWriteLock { |
| /** |
| * Returns the lock used for reading. |
| * |
| * @return the lock used for reading. |
| */ |
| Lock readLock(); |
| |
| /** |
| * Returns the lock used for writing. |
| * |
| * @return the lock used for writing. |
| */ |
| Lock writeLock(); |
| } |