lib/classpath/external/jsr166/java/util/concurrent/locks/ReadWriteLock.java

   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 &quot;in-order&quot; 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 }