1 /* 2 * @(#)ReadWriteLock.java 1.6 04/07/13 3 * 4 * Copyright 2004 Sun Microsystems, Inc. All rights reserved. 5 * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. 6 */ 7 8 package java.util.concurrent.locks; 9 10 /** 11 * A <tt>ReadWriteLock</tt> maintains a pair of associated {@link 12 * Lock locks}, one for read-only operations and one for writing. 13 * The {@link #readLock read lock} may be held simultaneously by 14 * multiple reader threads, so long as there are no writers. The 15 * {@link #writeLock write lock} is exclusive. 16 * 17 * <p>A read-write lock allows for a greater level of concurrency in 18 * accessing shared data than that permitted by a mutual exclusion lock. 19 * It exploits the fact that while only a single thread at a time (a 20 * <em>writer</em> thread) can modify the shared data, in many cases any 21 * number of threads can concurrently read the data (hence <em>reader</em> 22 * threads). 23 * In theory, the increase in concurrency permitted by the use of a read-write 24 * lock will lead to performance improvements over the use of a mutual 25 * exclusion lock. In practice this increase in concurrency will only be fully 26 * realized on a multi-processor, and then only if the access patterns for 27 * the shared data are suitable. 28 * 29 * <p>Whether or not a read-write lock will improve performance over the use 30 * of a mutual exclusion lock depends on the frequency that the data is 31 * read compared to being modified, the duration of the read and write 32 * operations, and the contention for the data - that is, the number of 33 * threads that will try to read or write the data at the same time. 34 * For example, a collection that is initially populated with data and 35 * thereafter infrequently modified, while being frequently searched 36 * (such as a directory of some kind) is an ideal candidate for the use of 37 * a read-write lock. However, if updates become frequent then the data 38 * spends most of its time being exclusively locked and there is little, if any 39 * increase in concurrency. Further, if the read operations are too short 40 * the overhead of the read-write lock implementation (which is inherently 41 * more complex than a mutual exclusion lock) can dominate the execution 42 * cost, particularly as many read-write lock implementations still serialize 43 * all threads through a small section of code. Ultimately, only profiling 44 * and measurement will establish whether the use of a read-write lock is 45 * suitable for your application. 46 * 47 * 48 * <p>Although the basic operation of a read-write lock is straight-forward, 49 * there are many policy decisions that an implementation must make, which 50 * may affect the effectiveness of the read-write lock in a given application. 51 * Examples of these policies include: 52 * <ul> 53 * <li>Determining whether to grant the read lock or the write lock, when 54 * both readers and writers are waiting, at the time that a writer releases 55 * the write lock. Writer preference is common, as writes are expected to be 56 * short and infrequent. Reader preference is less common as it can lead to 57 * lengthy delays for a write if the readers are frequent and long-lived as 58 * expected. Fair, or "in-order" implementations are also possible. 59 * 60 * <li>Determining whether readers that request the read lock while a 61 * reader is active and a writer is waiting, are granted the read lock. 62 * Preference to the reader can delay the writer indefinitely, while 63 * preference to the writer can reduce the potential for concurrency. 64 * 65 * <li>Determining whether the locks are reentrant: can a thread with the 66 * write lock reacquire it? Can it acquire a read lock while holding the 67 * write lock? Is the read lock itself reentrant? 68 * 69 * <li>Can the write lock be downgraded to a read lock without allowing 70 * an intervening writer? Can a read lock be upgraded to a write lock, 71 * in preference to other waiting readers or writers? 72 * 73 * </ul> 74 * You should consider all of these things when evaluating the suitability 75 * of a given implementation for your application. 76 * 77 * @see ReentrantReadWriteLock 78 * @see Lock 79 * @see ReentrantLock 80 * 81 * @since 1.5 82 * @author Doug Lea 83 */ 84 public interface ReadWriteLock { 85 /** 86 * Returns the lock used for reading. 87 * 88 * @return the lock used for reading. 89 */ 90 Lock readLock(); 91 92 /** 93 * Returns the lock used for writing. 94 * 95 * @return the lock used for writing. 96 */ 97 Lock writeLock(); 98 } 99