/*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation. Oracle designates this
* particular file as subject to the "Classpath" exception as provided
* by Oracle in the LICENSE file that accompanied this code.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
* or visit www.oracle.com if you need additional information or have any
* questions.
*/
/*
* This file is available under and governed by the GNU General Public
* License version 2 only, as published by the Free Software Foundation.
* However, the following notice accompanied the original version of this
* file:
*
* Written by Doug Lea with assistance from members of JCP JSR-166
* Expert Group and released to the public domain, as explained at
* http://creativecommons.org/publicdomain/zero/1.0/
*/
Interfaces and classes providing a framework for locking and waiting
for conditions that is distinct from built-in synchronization and
monitors. The framework permits much greater flexibility in the use of
locks and conditions, at the expense of more awkward syntax.
The Lock interface supports locking disciplines that differ in semantics (reentrant, fair, etc), and that can be used in non-block-structured contexts including hand-over-hand and lock reordering algorithms. The main implementation is ReentrantLock.
The ReadWriteLock interface similarly defines locks that may be shared among readers but are exclusive to writers. Only a single implementation, ReentrantReadWriteLock, is provided, since it covers most standard usage contexts. But programmers may create their own implementations to cover nonstandard requirements.
The Condition interface describes condition variables that may be associated with Locks. These are similar in usage to the implicit monitors accessed using Object.wait, but offer extended capabilities. In particular, multiple Condition objects may be associated with a single Lock. To avoid compatibility issues, the names of Condition methods are different from the corresponding Object versions.
The AbstractQueuedSynchronizer class serves as a useful superclass for defining locks and other synchronizers that rely on queuing blocked threads. The AbstractQueuedLongSynchronizer class provides the same functionality but extends support to 64 bits of synchronization state. Both extend class AbstractOwnableSynchronizer, a simple class that helps record the thread currently holding exclusive synchronization. The LockSupport class provides lower-level blocking and unblocking support that is useful for those developers implementing their own customized lock classes.
Since: 1.5
/**
* Interfaces and classes providing a framework for locking and waiting
* for conditions that is distinct from built-in synchronization and
* monitors. The framework permits much greater flexibility in the use of
* locks and conditions, at the expense of more awkward syntax.
*
* <p>The {@link java.util.concurrent.locks.Lock} interface supports
* locking disciplines that differ in semantics (reentrant, fair, etc),
* and that can be used in non-block-structured contexts including
* hand-over-hand and lock reordering algorithms. The main implementation
* is {@link java.util.concurrent.locks.ReentrantLock}.
*
* <p>The {@link java.util.concurrent.locks.ReadWriteLock} interface
* similarly defines locks that may be shared among readers but are
* exclusive to writers. Only a single implementation, {@link
* java.util.concurrent.locks.ReentrantReadWriteLock}, is provided, since
* it covers most standard usage contexts. But programmers may create
* their own implementations to cover nonstandard requirements.
*
* <p>The {@link java.util.concurrent.locks.Condition} interface
* describes condition variables that may be associated with Locks.
* These are similar in usage to the implicit monitors accessed using
* {@code Object.wait}, but offer extended capabilities.
* In particular, multiple {@code Condition} objects may be associated
* with a single {@code Lock}. To avoid compatibility issues, the
* names of {@code Condition} methods are different from the
* corresponding {@code Object} versions.
*
* <p>The {@link java.util.concurrent.locks.AbstractQueuedSynchronizer}
* class serves as a useful superclass for defining locks and other
* synchronizers that rely on queuing blocked threads. The {@link
* java.util.concurrent.locks.AbstractQueuedLongSynchronizer} class
* provides the same functionality but extends support to 64 bits of
* synchronization state. Both extend class {@link
* java.util.concurrent.locks.AbstractOwnableSynchronizer}, a simple
* class that helps record the thread currently holding exclusive
* synchronization. The {@link java.util.concurrent.locks.LockSupport}
* class provides lower-level blocking and unblocking support that is
* useful for those developers implementing their own customized lock
* classes.
*
* @since 1.5
*/
package java.util.concurrent.locks;