ReadWriteLock


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 &quot;in-order&quot; 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
A to Z: JavaDoc & Examples Daily Java News & Articles Open Source Projects Open Source Codes Free Computer Books Remove Frame
Popular Tags