001 /*
002 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
003 *
004 * This code is free software; you can redistribute it and/or modify it
005 * under the terms of the GNU General Public License version 2 only, as
006 * published by the Free Software Foundation. Sun designates this
007 * particular file as subject to the "Classpath" exception as provided
008 * by Sun in the LICENSE file that accompanied this code.
009 *
010 * This code is distributed in the hope that it will be useful, but WITHOUT
011 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
012 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
013 * version 2 for more details (a copy is included in the LICENSE file that
014 * accompanied this code).
015 *
016 * You should have received a copy of the GNU General Public License version
017 * 2 along with this work; if not, write to the Free Software Foundation,
018 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
019 *
020 * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
021 * CA 95054 USA or visit www.sun.com if you need additional information or
022 * have any questions.
023 */
024
025 /*
026 * This file is available under and governed by the GNU General Public
027 * License version 2 only, as published by the Free Software Foundation.
028 * However, the following notice accompanied the original version of this
029 * file:
030 *
031 * Written by Doug Lea with assistance from members of JCP JSR-166
032 * Expert Group and released to the public domain, as explained at
033 * http://creativecommons.org/licenses/publicdomain
034 */
035
036 package java.util.concurrent.locks;
037
038 /**
039 * A <tt>ReadWriteLock</tt> maintains a pair of associated {@link
040 * Lock locks}, one for read-only operations and one for writing.
041 * The {@link #readLock read lock} may be held simultaneously by
042 * multiple reader threads, so long as there are no writers. The
043 * {@link #writeLock write lock} is exclusive.
044 *
045 * <p>All <tt>ReadWriteLock</tt> implementations must guarantee that
046 * the memory synchronization effects of <tt>writeLock</tt> operations
047 * (as specified in the {@link Lock} interface) also hold with respect
048 * to the associated <tt>readLock</tt>. That is, a thread successfully
049 * acquiring the read lock will see all updates made upon previous
050 * release of the write lock.
051 *
052 * <p>A read-write lock allows for a greater level of concurrency in
053 * accessing shared data than that permitted by a mutual exclusion lock.
054 * It exploits the fact that while only a single thread at a time (a
055 * <em>writer</em> thread) can modify the shared data, in many cases any
056 * number of threads can concurrently read the data (hence <em>reader</em>
057 * threads).
058 * In theory, the increase in concurrency permitted by the use of a read-write
059 * lock will lead to performance improvements over the use of a mutual
060 * exclusion lock. In practice this increase in concurrency will only be fully
061 * realized on a multi-processor, and then only if the access patterns for
062 * the shared data are suitable.
063 *
064 * <p>Whether or not a read-write lock will improve performance over the use
065 * of a mutual exclusion lock depends on the frequency that the data is
066 * read compared to being modified, the duration of the read and write
067 * operations, and the contention for the data - that is, the number of
068 * threads that will try to read or write the data at the same time.
069 * For example, a collection that is initially populated with data and
070 * thereafter infrequently modified, while being frequently searched
071 * (such as a directory of some kind) is an ideal candidate for the use of
072 * a read-write lock. However, if updates become frequent then the data
073 * spends most of its time being exclusively locked and there is little, if any
074 * increase in concurrency. Further, if the read operations are too short
075 * the overhead of the read-write lock implementation (which is inherently
076 * more complex than a mutual exclusion lock) can dominate the execution
077 * cost, particularly as many read-write lock implementations still serialize
078 * all threads through a small section of code. Ultimately, only profiling
079 * and measurement will establish whether the use of a read-write lock is
080 * suitable for your application.
081 *
082 *
083 * <p>Although the basic operation of a read-write lock is straight-forward,
084 * there are many policy decisions that an implementation must make, which
085 * may affect the effectiveness of the read-write lock in a given application.
086 * Examples of these policies include:
087 * <ul>
088 * <li>Determining whether to grant the read lock or the write lock, when
089 * both readers and writers are waiting, at the time that a writer releases
090 * the write lock. Writer preference is common, as writes are expected to be
091 * short and infrequent. Reader preference is less common as it can lead to
092 * lengthy delays for a write if the readers are frequent and long-lived as
093 * expected. Fair, or "in-order" implementations are also possible.
094 *
095 * <li>Determining whether readers that request the read lock while a
096 * reader is active and a writer is waiting, are granted the read lock.
097 * Preference to the reader can delay the writer indefinitely, while
098 * preference to the writer can reduce the potential for concurrency.
099 *
100 * <li>Determining whether the locks are reentrant: can a thread with the
101 * write lock reacquire it? Can it acquire a read lock while holding the
102 * write lock? Is the read lock itself reentrant?
103 *
104 * <li>Can the write lock be downgraded to a read lock without allowing
105 * an intervening writer? Can a read lock be upgraded to a write lock,
106 * in preference to other waiting readers or writers?
107 *
108 * </ul>
109 * You should consider all of these things when evaluating the suitability
110 * of a given implementation for your application.
111 *
112 * @see ReentrantReadWriteLock
113 * @see Lock
114 * @see ReentrantLock
115 *
116 * @since 1.5
117 * @author Doug Lea
118 */
119 public interface ReadWriteLock {
120 /**
121 * Returns the lock used for reading.
122 *
123 * @return the lock used for reading.
124 */
125 Lock readLock();
126
127 /**
128 * Returns the lock used for writing.
129 *
130 * @return the lock used for writing.
131 */
132 Lock writeLock();
133 }
|