content: /*
   * 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/
   */
  
  package java.util.concurrent.locks;
  
  import java.util.Date;
  import java.util.concurrent.TimeUnit;
  
  /**
   * {@code Condition} factors out the {@code 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, by
   * combining them with the use of arbitrary {@link Lock} implementations.
   * Where a {@code Lock} replaces the use of {@code synchronized} methods
   * and statements, a {@code Condition} replaces the use of the Object
   * monitor methods.
   *
   * <p>Conditions (also known as <em>condition queues</em> or
   * <em>condition variables</em>) provide a means for one thread to
   * suspend execution (to &quot;wait&quot;) 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, so a lock of some form is associated with the
   * condition. The key property that waiting for a condition provides
   * is that it <em>atomically</em> releases the associated lock and
   * suspends the current thread, just like {@code Object.wait}.
   *
   * <p>A {@code Condition} instance is intrinsically bound to a lock.
   * To obtain a {@code Condition} instance for a particular {@link Lock}
   * instance use its {@link Lock#newCondition newCondition()} method.
   *
   * <p>As an example, suppose we have a bounded buffer which supports
   * {@code put} and {@code take} methods.  If a
   * {@code take} is attempted on an empty buffer, then the thread will block
   * until an item becomes available; if a {@code put} is attempted on a
   * full buffer, then the thread will block until a space becomes available.
   * We would like to keep waiting {@code put} threads and {@code take}
   * threads in separate wait-sets so that we can use the optimization of
   * only notifying a single thread at a time when items or spaces become
   * available in the buffer. This can be achieved using two
   * {@link Condition} instances.
   * <pre>
   * class BoundedBuffer {
   *   <b>final Lock lock = new ReentrantLock();</b>
   *   final Condition notFull  = <b>lock.newCondition(); </b>
   *   final Condition notEmpty = <b>lock.newCondition(); </b>
   *
   *   final Object[] items = new Object[100];
   *   int putptr, takeptr, count;
   *
   *   public void put(Object x) throws InterruptedException {
   *     <b>lock.lock();
   *     try {</b>
   *       while (count == items.length)
   *         <b>notFull.await();</b>
   *       items[putptr] = x;
   *       if (++putptr == items.length) putptr = 0;
   *       ++count;
   *       <b>notEmpty.signal();</b>
   *     <b>} finally {
   *       lock.unlock();
   *     }</b>
   *   }
   *
   *   public Object take() throws InterruptedException {
   *     <b>lock.lock();
   *     try {</b>
   *       while (count == 0)
   *         <b>notEmpty.await();</b>
   *       Object x = items[takeptr];
   *       if (++takeptr == items.length) takeptr = 0;
   *       --count;
   *       <b>notFull.signal();</b>
   *       return x;
   *     <b>} finally {
   *       lock.unlock();
   *     }</b>
   *   }
   * }
   * </pre>
   *
   * (The {@link java.util.concurrent.ArrayBlockingQueue} class provides
   * this functionality, so there is no reason to implement this
   * sample usage class.)
   *
   * <p>A {@code Condition} implementation can provide behavior and semantics
   * that is
   * different from that of the {@code 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 specialized semantics then the
   * implementation must document those semantics.
   *
   * <p>Note that {@code Condition} instances are just normal objects and can
   * themselves be used as the target in a {@code synchronized} statement,
   * and can have their own monitor {@link Object#wait wait} and
   * {@link Object#notify notify} methods invoked.
   * Acquiring the monitor lock of a {@code Condition} instance, or using its
   * monitor methods, has no specified relationship with acquiring the
   * {@link Lock} associated with that {@code Condition} or the use of its
   * {@linkplain #await waiting} and {@linkplain #signal signalling} methods.
   * It is recommended that to avoid confusion you never use {@code Condition}
   * instances in this way, except perhaps within their own implementation.
   *
   * <p>Except where noted, passing a {@code null} value for any parameter
   * will result in a {@link NullPointerException} being thrown.
   *
   * <h3>Implementation Considerations</h3>
   *
   * <p>When waiting upon a {@code Condition}, a &quot;<em>spurious
   * wakeup</em>&quot; 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
   * {@code 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.
   *
   * <p>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.
   *
   * <p>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.
   *
   * <p>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.
   *
   * <p>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 that may have
   * unblocked the thread. An implementation should document this behavior.
   *
   * @since 1.5
   * @author Doug Lea
   */
  public interface Condition {
  
      /**
       * Causes the current thread to wait until it is signalled or
       * {@linkplain Thread#interrupt interrupted}.
       *
       * <p>The lock associated with this {@code Condition} is atomically
       * released and the current thread becomes disabled for thread scheduling
       * purposes and lies dormant until <em>one</em> of four things happens:
       * <ul>
       * <li>Some other thread invokes the {@link #signal} method for this
       * {@code Condition} and the current thread happens to be chosen as the
       * thread to be awakened; or
       * <li>Some other thread invokes the {@link #signalAll} method for this
       * {@code Condition}; or
       * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
       * current thread, and interruption of thread suspension is supported; or
       * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
       * </ul>
       *
       * <p>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 <em>guaranteed</em> to hold this lock.
       *
       * <p>If the current thread:
       * <ul>
       * <li>has its interrupted status set on entry to this method; or
       * <li>is {@linkplain Thread#interrupt interrupted} while waiting
       * and interruption of thread suspension is supported,
       * </ul>
       * then {@link InterruptedException} is thrown and the current thread's
       * interrupted status is cleared. It is not specified, in the first
       * case, whether or not the test for interruption occurs before the lock
       * is released.
       *
       * <p><b>Implementation Considerations</b>
       *
       * <p>The current thread is assumed to hold the lock associated with this
       * {@code 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.
       *
       * <p>An implementation can favor 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.
       *
       * <p>The lock associated with this condition is atomically
       * released and the current thread becomes disabled for thread scheduling
       * purposes and lies dormant until <em>one</em> of three things happens:
       * <ul>
       * <li>Some other thread invokes the {@link #signal} method for this
       * {@code Condition} and the current thread happens to be chosen as the
       * thread to be awakened; or
       * <li>Some other thread invokes the {@link #signalAll} method for this
       * {@code Condition}; or
       * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
       * </ul>
       *
       * <p>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 <em>guaranteed</em> to hold this lock.
       *
       * <p>If the current thread's interrupted status is set when it enters
       * this method, or it is {@linkplain Thread#interrupt interrupted}
       * while waiting, it will continue to wait until signalled. When it finally
       * returns from this method its interrupted status will still
       * be set.
       *
       * <p><b>Implementation Considerations</b>
       *
       * <p>The current thread is assumed to hold the lock associated with this
       * {@code 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.
       *
       * <p>The lock associated with this condition is atomically
       * released and the current thread becomes disabled for thread scheduling
       * purposes and lies dormant until <em>one</em> of five things happens:
       * <ul>
       * <li>Some other thread invokes the {@link #signal} method for this
       * {@code Condition} and the current thread happens to be chosen as the
       * thread to be awakened; or
       * <li>Some other thread invokes the {@link #signalAll} method for this
       * {@code Condition}; or
       * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
       * current thread, and interruption of thread suspension is supported; or
       * <li>The specified waiting time elapses; or
       * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
       * </ul>
       *
       * <p>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 <em>guaranteed</em> to hold this lock.
       *
       * <p>If the current thread:
       * <ul>
       * <li>has its interrupted status set on entry to this method; or
       * <li>is {@linkplain Thread#interrupt interrupted} while waiting
       * and interruption of thread suspension is supported,
       * </ul>
       * then {@link InterruptedException} is thrown and the current thread's
       * interrupted status is cleared. It is not specified, in the first
       * case, whether or not the test for interruption occurs before the lock
       * is released.
       *
       * <p>The method returns an estimate of the number of nanoseconds
       * remaining to wait given the supplied {@code 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:
       *
       * <pre> {@code
       * boolean aMethod(long timeout, TimeUnit unit) {
       *   long nanos = unit.toNanos(timeout);
       *   lock.lock();
       *   try {
       *     while (!conditionBeingWaitedFor()) {
       *       if (nanos <= 0L)
       *         return false;
       *       nanos = theCondition.awaitNanos(nanos);
       *     }
       *     // ...
       *   } finally {
       *     lock.unlock();
       *   }
       * }}</pre>
       *
       * <p>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.
       *
       * <p><b>Implementation Considerations</b>
       *
       * <p>The current thread is assumed to hold the lock associated with this
       * {@code 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.
       *
       * <p>An implementation can favor 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 an estimate of the {@code nanosTimeout} value minus
       *         the time spent waiting upon return from this method.
       *         A positive value may be used as the argument to a
       *         subsequent call to this method to finish waiting out
       *         the desired time.  A value less than or equal to zero
       *         indicates that no time remains.
       * @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:
       * <pre> {@code awaitNanos(unit.toNanos(time)) > 0}</pre>
       *
       * @param time the maximum time to wait
       * @param unit the time unit of the {@code time} argument
       * @return {@code false} if the waiting time detectably elapsed
       *         before return from the method, else {@code 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.
       *
       * <p>The lock associated with this condition is atomically
       * released and the current thread becomes disabled for thread scheduling
       * purposes and lies dormant until <em>one</em> of five things happens:
       * <ul>
       * <li>Some other thread invokes the {@link #signal} method for this
       * {@code Condition} and the current thread happens to be chosen as the
       * thread to be awakened; or
       * <li>Some other thread invokes the {@link #signalAll} method for this
       * {@code Condition}; or
       * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
       * current thread, and interruption of thread suspension is supported; or
       * <li>The specified deadline elapses; or
       * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
       * </ul>
       *
       * <p>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 <em>guaranteed</em> to hold this lock.
       *
       *
       * <p>If the current thread:
       * <ul>
       * <li>has its interrupted status set on entry to this method; or
       * <li>is {@linkplain Thread#interrupt interrupted} while waiting
       * and interruption of thread suspension is supported,
       * </ul>
       * then {@link InterruptedException} is thrown and the current thread's
       * interrupted status is cleared. It is not specified, in the first
       * case, whether or not the test for interruption occurs before the lock
       * is released.
       *
       *
       * <p>The return value indicates whether the deadline has elapsed,
       * which can be used as follows:
       * <pre> {@code
       * boolean aMethod(Date deadline) {
       *   boolean stillWaiting = true;
       *   lock.lock();
       *   try {
       *     while (!conditionBeingWaitedFor()) {
       *       if (!stillWaiting)
       *         return false;
       *       stillWaiting = theCondition.awaitUntil(deadline);
       *     }
       *     // ...
       *   } finally {
       *     lock.unlock();
       *   }
       * }}</pre>
       *
       * <p><b>Implementation Considerations</b>
       *
       * <p>The current thread is assumed to hold the lock associated with this
       * {@code 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.
       *
       * <p>An implementation can favor 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 {@code false} if the deadline has elapsed upon return, else
       *         {@code 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.
       *
       * <p>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 {@code await}.
       *
       * <p><b>Implementation Considerations</b>
       *
       * <p>An implementation may (and typically does) require that the
       * current thread hold the lock associated with this {@code
       * Condition} when this method is called. Implementations must
       * document this precondition and any actions taken if the lock is
       * not held. Typically, an exception such as {@link
       * IllegalMonitorStateException} will be thrown.
       */
      void signal();
  
      /**
       * Wakes up all waiting threads.
       *
       * <p>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 {@code await}.
       *
       * <p><b>Implementation Considerations</b>
       *
       * <p>An implementation may (and typically does) require that the
       * current thread hold the lock associated with this {@code
       * Condition} when this method is called. Implementations must
       * document this precondition and any actions taken if the lock is
       * not held. Typically, an exception such as {@link
       * IllegalMonitorStateException} will be thrown.
       */
      void signalAll();
  }
  