/* * Written by Doug Lea with assistance from members of JCP JSR-166 * Expert Group and released to the public domain. Use, modify, and * redistribute this code in any way without acknowledgement. */ package java.util.concurrent; import java.util.Date; /** * Condition factors out the Object monitor * methods ({@link Object#wait() wait}, {@link Object#notify notify} * and {@link Object#notifyAll notifyAll}) into distinct objects to * give the effect of having multiple wait-sets per object * monitor. It also generalises the monitor methods to allow them to * be used with arbitrary {@link Lock} implementations when needed. * *
Conditions (also known as condition queues or * condition variables) provide * a means for one thread to suspend execution (to "wait") until * notified by another thread that some state condition may now be true. * Because access to this shared state information * occurs in different threads, it must be protected, and invariably * a lock of some form is associated with the condition. The key * property that waiting for a condition provides is that it * atomically releases the associated lock and suspends the current * thread, just like Object.wait. * *
A Condition instance is intrinsically bound to a lock, either * the built-in monitor lock of an object, or a {@link Lock} instance. * To obtain a Condition instance for a particular object's monitor * lock * use the {@link Locks#newConditionFor(Object)} method. * To obtain a Condition instance for a particular {@link Lock} * instance use its {@link Lock#newCondition} method. * *
As an example, suppose we have a bounded buffer which supports * put and take methods. If a * take is attempted on an empty buffer, then the thread will block * until an item becomes available; if a put is attempted on a * full buffer, then the thread will block until a space becomes available. * We would like to keep waiting put threads and take * threads in separate wait-sets so that we can use the optimisation of * only notifying a single thread at a time when items or spaces become * available in the buffer. This can be achieved using either two * {@link Condition} instances, or one {@link Condition} instance and the * actual * monitor wait-set. For clarity we'll use two {@link Condition} instances. *
* class BoundedBuffer {
* final Condition notFull = Locks.newConditionFor(this);
* final Condition notEmpty = Locks.newConditionFor(this);
*
* Object[] items = new Object[100];
* int putptr, takeptr, count;
*
* public synchronized void put(Object x)
* throws InterruptedException {
* while (count == items.length)
* notFull.await();
* items[putptr] = x;
* if (++putptr == items.length) putptr = 0;
* ++count;
* notEmpty.signal();
* }
*
* public synchronized Object take() throws InterruptedException {
* while (count == 0)
* notEmpty.await();
* Object x = items[takeptr];
* if (++takeptr == items.length) takeptr = 0;
* --count;
* notFull.signal();
* return x;
* }
* }
*
*
* If we were to use a standalone {@link Lock} object, such as a * {@link ReentrantLock} then we would write the example as so: *
* class BoundedBuffer {
* Lock lock = new ReentrantLock();
* final Condition notFull = lock.newCondition();
* final Condition notEmpty = lock.newCondition();
*
* Object[] items = new Object[100];
* int putptr, takeptr, count;
*
* public void put(Object x) throws InterruptedException {
* lock.lock();
* try {
* while (count == items.length)
* notFull.await();
* items[putptr] = x;
* if (++putptr == items.length) putptr = 0;
* ++count;
* notEmpty.signal();
* } finally {
* lock.unlock();
* }
* }
*
* public Object take() throws InterruptedException {
* lock.lock();
* try {
* while (count == 0)
* notEmpty.await();
* Object x = items[takeptr];
* if (++takeptr == items.length) takeptr = 0;
* --count;
* notFull.signal();
* return x;
* } finally {
* lock.unlock();
* }
* }
* }
*
*
* A Condition implementation can provide behavior and semantics * that is * different from that of the Object monitor methods, such as * guaranteed ordering for notifications, or not requiring a lock to be held * when performing notifications. * If an implementation provides such specialised semantics then the * implementation must document those semantics. * *
Note that Condition instances are just normal objects and can * themselves be used as the target in a synchronized statement, * and can have their own monitor {@link Object#wait wait} and * {@link Object#notify notification} methods invoked. * Acquiring the monitor lock of a Condition instance, or using its * monitor methods, has no specified relationship with acquiring the * {@link Lock} associated with that Condition or the use of it's * {@link #await waiting} and {@link #signal signalling} methods. * It is recommended that to avoid confusion you never use Condition * instances in this way, except perhaps within their own implementation. * *
Except where noted, passing a null value for any parameter * will result in a {@link NullPointerException} being thrown. * *
When waiting upon a Condition, a "spurious * wakeup" is permitted to occur, in * general, as a concession to the underlying platform semantics. * This has little practical impact on most application programs as a * Condition should always be waited upon in a loop, testing * the state predicate that is being waited for. An implementation is * free to remove the possibility of spurious wakeups but it is * recommended that applications programmers always assume that they can * occur and so always wait in a loop. * *
The three forms of condition waiting * (interruptible, non-interruptible, and timed) may differ in their ease of * implementation on some platforms and in their performance characteristics. * In particular, it may be difficult to provide these features and maintain * specific semantics such as ordering guarantees. * Further, the ability to interrupt the actual suspension of the thread may * not always be feasible to implement on all platforms. *
Consequently, an implementation is not required to define exactly the * same guarantees or semantics for all three forms of waiting, nor is it * required to support interruption of the actual suspension of the thread. *
An implementation is required to * clearly document the semantics and guarantees provided by each of the * waiting methods, and when an implementation does support interruption of * thread suspension then it must obey the interruption semantics as defined * in this interface. *
As interruption generally implies cancellation, and checks for * interruption are often infrequent, an implementation can favor responding * to an interrupt over normal method return. This is true even if it can be * shown that the interrupt occurred after another action may have unblocked * the thread. An implementation should document this behaviour. * * * @since 1.5 * @spec JSR-166 * @revised $Date: 2003/07/08 00:46:33 $ * @editor $Author: dl $ * @author Doug Lea */ public interface Condition { /** * Causes the current thread to wait until it is signalled or * {@link Thread#interrupt interrupted}. * *
The lock associated with this Condition is atomically * released and the current thread becomes disabled for thread scheduling * purposes and lies dormant until one of four things happens: *
In all cases, before this method can return the current thread must * re-acquire the lock associated with this condition. When the * thread returns it is guaranteed to hold this lock. * *
If the current thread: *
Implementation Considerations *
The current thread is assumed to hold the lock associated with this * Condition when this method is called. * It is up to the implementation to determine if this is * the case and if not, how to respond. Typically, an exception will be * thrown (such as {@link IllegalMonitorStateException}) and the * implementation must document that fact. * *
An implementation can favour responding to an interrupt over normal * method return in response to a signal. In that case the implementation * must ensure that the signal is redirected to another waiting thread, if * there is one. * * @throws InterruptedException if the current thread is interrupted (and * interruption of thread suspension is supported). **/ void await() throws InterruptedException; /** * Causes the current thread to wait until it is signalled. * *
The lock associated with this condition is atomically * released and the current thread becomes disabled for thread scheduling * purposes and lies dormant until one of three things happens: *
In all cases, before this method can return the current thread must * re-acquire the lock associated with this condition. When the * thread returns it is guaranteed to hold this lock. * *
If the current thread's interrupt status is set when it enters * this method, or it is {@link Thread#interrupt interrupted} * while waiting, it will continue to wait until signalled. When it finally * returns from this method it's interrupted status will still * be set. * *
Implementation Considerations *
The current thread is assumed to hold the lock associated with this * Condition when this method is called. * It is up to the implementation to determine if this is * the case and if not, how to respond. Typically, an exception will be * thrown (such as {@link IllegalMonitorStateException}) and the * implementation must document that fact. * **/ void awaitUninterruptibly(); /** * Causes the current thread to wait until it is signalled or interrupted, * or the specified waiting time elapses. * *
The lock associated with this condition is atomically * released and the current thread becomes disabled for thread scheduling * purposes and lies dormant until one of five things happens: *
In all cases, before this method can return the current thread must * re-acquire the lock associated with this condition. When the * thread returns it is guaranteed to hold this lock. * *
If the current thread: *
The method returns an estimate of the number of nanoseconds * remaining to wait given the supplied nanosTimeout * value upon return, or a value less than or equal to zero if it * timed out. This value can be used to determine whether and how * long to re-wait in cases where the wait returns but an awaited * condition still does not hold. Typical uses of this method take * the following form: * *
* synchronized boolean aMethod(long timeout, TimeUnit unit) { * long nanosTimeout = unit.toNanos(timeout); * while (!conditionBeingWaitedFor) { * if (nanosTimeout > 0) * nanosTimeout = theCondition.awaitNanos(nanosTimeout); * else * return false; * } * // ... * } ** *
Design note: This method requires a nanosecond argument so * as to avoid truncation errors in reporting remaining times. * Such precision loss would make it difficult for programmers to * ensure that total waiting times are not systematically shorter * than specified when re-waits occur. * *
Implementation Considerations *
The current thread is assumed to hold the lock associated with this * Condition when this method is called. * It is up to the implementation to determine if this is * the case and if not, how to respond. Typically, an exception will be * thrown (such as {@link IllegalMonitorStateException}) and the * implementation must document that fact. * *
An implementation can favour responding to an interrupt over normal
* method return in response to a signal, or over indicating the elapse
* of the specified waiting time. In either case the implementation
* must ensure that the signal is redirected to another waiting thread, if
* there is one.
*
* @param nanosTimeout the maximum time to wait, in nanoseconds
* @return A value less than or equal to zero if the wait has
* timed out; otherwise an estimate, that
* is strictly less than the nanosTimeout argument,
* of the time still remaining when this method returned.
*
* @throws InterruptedException if the current thread is interrupted (and
* interruption of thread suspension is supported).
*/
long awaitNanos(long nanosTimeout) throws InterruptedException;
/**
* Causes the current thread to wait until it is signalled or interrupted,
* or the specified waiting time elapses. This method is behaviorally
* equivalent to:
*
* awaitNanos(unit.toNanos(time)) > 0 ** @param time the maximum time to wait * @param unit the time unit of the time argument. * @return false if the waiting time detectably elapsed * before return from the method, else true. * @throws InterruptedException if the current thread is interrupted (and * interruption of thread suspension is supported). */ boolean await(long time, TimeUnit unit) throws InterruptedException; /** * Causes the current thread to wait until it is signalled or interrupted, * or the specified deadline elapses. * *
The lock associated with this condition is atomically * released and the current thread becomes disabled for thread scheduling * purposes and lies dormant until one of five things happens: *
In all cases, before this method can return the current thread must * re-acquire the lock associated with this condition. When the * thread returns it is guaranteed to hold this lock. * * *
If the current thread: *
The return value idicates whether the deadline has elapsed, * which can be used as follows: *
* synchronized boolean aMethod(Date deadline) { * boolean stillWaiting = true; * while (!conditionBeingWaitedFor) { * if (stillwaiting) * stillWaiting = theCondition.awaitUntil(deadline); * else * return false; * } * // ... * } ** *
Implementation Considerations *
The current thread is assumed to hold the lock associated with this * Condition when this method is called. * It is up to the implementation to determine if this is * the case and if not, how to respond. Typically, an exception will be * thrown (such as {@link IllegalMonitorStateException}) and the * implementation must document that fact. * *
An implementation can favour responding to an interrupt over normal * method return in response to a signal, or over indicating the passing * of the specified deadline. In either case the implementation * must ensure that the signal is redirected to another waiting thread, if * there is one. * * * @param deadline the absolute time to wait until * @return false if the deadline has * elapsed upon return, else true. * * @throws InterruptedException if the current thread is interrupted (and * interruption of thread suspension is supported). */ boolean awaitUntil(Date deadline) throws InterruptedException; /** * Wakes up one waiting thread. * *
If any threads are waiting on this condition then one * is selected for waking up. That thread must then re-acquire the * lock before returning from await. **/ void signal(); /** * Wake up all waiting threads. * *
If any threads are waiting on this condition then they are * all woken up. Each thread must re-acquire the lock before it can * return from await. **/ void signalAll(); }