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