jaroslav@1890: /*
jaroslav@1890:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
jaroslav@1890:  *
jaroslav@1890:  * This code is free software; you can redistribute it and/or modify it
jaroslav@1890:  * under the terms of the GNU General Public License version 2 only, as
jaroslav@1890:  * published by the Free Software Foundation.  Oracle designates this
jaroslav@1890:  * particular file as subject to the "Classpath" exception as provided
jaroslav@1890:  * by Oracle in the LICENSE file that accompanied this code.
jaroslav@1890:  *
jaroslav@1890:  * This code is distributed in the hope that it will be useful, but WITHOUT
jaroslav@1890:  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
jaroslav@1890:  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
jaroslav@1890:  * version 2 for more details (a copy is included in the LICENSE file that
jaroslav@1890:  * accompanied this code).
jaroslav@1890:  *
jaroslav@1890:  * You should have received a copy of the GNU General Public License version
jaroslav@1890:  * 2 along with this work; if not, write to the Free Software Foundation,
jaroslav@1890:  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
jaroslav@1890:  *
jaroslav@1890:  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
jaroslav@1890:  * or visit www.oracle.com if you need additional information or have any
jaroslav@1890:  * questions.
jaroslav@1890:  */
jaroslav@1890: 
jaroslav@1890: /*
jaroslav@1890:  * This file is available under and governed by the GNU General Public
jaroslav@1890:  * License version 2 only, as published by the Free Software Foundation.
jaroslav@1890:  * However, the following notice accompanied the original version of this
jaroslav@1890:  * file:
jaroslav@1890:  *
jaroslav@1890:  * Written by Doug Lea with assistance from members of JCP JSR-166
jaroslav@1890:  * Expert Group and released to the public domain, as explained at
jaroslav@1890:  * http://creativecommons.org/publicdomain/zero/1.0/
jaroslav@1890:  */
jaroslav@1890: 
jaroslav@1890: package java.util.concurrent.locks;
jaroslav@1890: 
jaroslav@1890: /**
jaroslav@1890:  * A <tt>ReadWriteLock</tt> maintains a pair of associated {@link
jaroslav@1890:  * Lock locks}, one for read-only operations and one for writing.
jaroslav@1890:  * The {@link #readLock read lock} may be held simultaneously by
jaroslav@1890:  * multiple reader threads, so long as there are no writers.  The
jaroslav@1890:  * {@link #writeLock write lock} is exclusive.
jaroslav@1890:  *
jaroslav@1890:  * <p>All <tt>ReadWriteLock</tt> implementations must guarantee that
jaroslav@1890:  * the memory synchronization effects of <tt>writeLock</tt> operations
jaroslav@1890:  * (as specified in the {@link Lock} interface) also hold with respect
jaroslav@1890:  * to the associated <tt>readLock</tt>. That is, a thread successfully
jaroslav@1890:  * acquiring the read lock will see all updates made upon previous
jaroslav@1890:  * release of the write lock.
jaroslav@1890:  *
jaroslav@1890:  * <p>A read-write lock allows for a greater level of concurrency in
jaroslav@1890:  * accessing shared data than that permitted by a mutual exclusion lock.
jaroslav@1890:  * It exploits the fact that while only a single thread at a time (a
jaroslav@1890:  * <em>writer</em> thread) can modify the shared data, in many cases any
jaroslav@1890:  * number of threads can concurrently read the data (hence <em>reader</em>
jaroslav@1890:  * threads).
jaroslav@1890:  * In theory, the increase in concurrency permitted by the use of a read-write
jaroslav@1890:  * lock will lead to performance improvements over the use of a mutual
jaroslav@1890:  * exclusion lock. In practice this increase in concurrency will only be fully
jaroslav@1890:  * realized on a multi-processor, and then only if the access patterns for
jaroslav@1890:  * the shared data are suitable.
jaroslav@1890:  *
jaroslav@1890:  * <p>Whether or not a read-write lock will improve performance over the use
jaroslav@1890:  * of a mutual exclusion lock depends on the frequency that the data is
jaroslav@1890:  * read compared to being modified, the duration of the read and write
jaroslav@1890:  * operations, and the contention for the data - that is, the number of
jaroslav@1890:  * threads that will try to read or write the data at the same time.
jaroslav@1890:  * For example, a collection that is initially populated with data and
jaroslav@1890:  * thereafter infrequently modified, while being frequently searched
jaroslav@1890:  * (such as a directory of some kind) is an ideal candidate for the use of
jaroslav@1890:  * a read-write lock. However, if updates become frequent then the data
jaroslav@1890:  * spends most of its time being exclusively locked and there is little, if any
jaroslav@1890:  * increase in concurrency. Further, if the read operations are too short
jaroslav@1890:  * the overhead of the read-write lock implementation (which is inherently
jaroslav@1890:  * more complex than a mutual exclusion lock) can dominate the execution
jaroslav@1890:  * cost, particularly as many read-write lock implementations still serialize
jaroslav@1890:  * all threads through a small section of code. Ultimately, only profiling
jaroslav@1890:  * and measurement will establish whether the use of a read-write lock is
jaroslav@1890:  * suitable for your application.
jaroslav@1890:  *
jaroslav@1890:  *
jaroslav@1890:  * <p>Although the basic operation of a read-write lock is straight-forward,
jaroslav@1890:  * there are many policy decisions that an implementation must make, which
jaroslav@1890:  * may affect the effectiveness of the read-write lock in a given application.
jaroslav@1890:  * Examples of these policies include:
jaroslav@1890:  * <ul>
jaroslav@1890:  * <li>Determining whether to grant the read lock or the write lock, when
jaroslav@1890:  * both readers and writers are waiting, at the time that a writer releases
jaroslav@1890:  * the write lock. Writer preference is common, as writes are expected to be
jaroslav@1890:  * short and infrequent. Reader preference is less common as it can lead to
jaroslav@1890:  * lengthy delays for a write if the readers are frequent and long-lived as
jaroslav@1890:  * expected. Fair, or &quot;in-order&quot; implementations are also possible.
jaroslav@1890:  *
jaroslav@1890:  * <li>Determining whether readers that request the read lock while a
jaroslav@1890:  * reader is active and a writer is waiting, are granted the read lock.
jaroslav@1890:  * Preference to the reader can delay the writer indefinitely, while
jaroslav@1890:  * preference to the writer can reduce the potential for concurrency.
jaroslav@1890:  *
jaroslav@1890:  * <li>Determining whether the locks are reentrant: can a thread with the
jaroslav@1890:  * write lock reacquire it? Can it acquire a read lock while holding the
jaroslav@1890:  * write lock? Is the read lock itself reentrant?
jaroslav@1890:  *
jaroslav@1890:  * <li>Can the write lock be downgraded to a read lock without allowing
jaroslav@1890:  * an intervening writer? Can a read lock be upgraded to a write lock,
jaroslav@1890:  * in preference to other waiting readers or writers?
jaroslav@1890:  *
jaroslav@1890:  * </ul>
jaroslav@1890:  * You should consider all of these things when evaluating the suitability
jaroslav@1890:  * of a given implementation for your application.
jaroslav@1890:  *
jaroslav@1890:  * @see ReentrantReadWriteLock
jaroslav@1890:  * @see Lock
jaroslav@1890:  * @see ReentrantLock
jaroslav@1890:  *
jaroslav@1890:  * @since 1.5
jaroslav@1890:  * @author Doug Lea
jaroslav@1890:  */
jaroslav@1890: public interface ReadWriteLock {
jaroslav@1890:     /**
jaroslav@1890:      * Returns the lock used for reading.
jaroslav@1890:      *
jaroslav@1890:      * @return the lock used for reading.
jaroslav@1890:      */
jaroslav@1890:     Lock readLock();
jaroslav@1890: 
jaroslav@1890:     /**
jaroslav@1890:      * Returns the lock used for writing.
jaroslav@1890:      *
jaroslav@1890:      * @return the lock used for writing.
jaroslav@1890:      */
jaroslav@1890:     Lock writeLock();
jaroslav@1890: }