/* * 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 {@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}. * *
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. * *
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. * *
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;