1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/rt/emul/compact/src/main/java/java/util/concurrent/locks/Condition.java Sat Mar 19 10:46:31 2016 +0100
1.3 @@ -0,0 +1,488 @@
1.4 +/*
1.5 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
1.6 + *
1.7 + * This code is free software; you can redistribute it and/or modify it
1.8 + * under the terms of the GNU General Public License version 2 only, as
1.9 + * published by the Free Software Foundation. Oracle designates this
1.10 + * particular file as subject to the "Classpath" exception as provided
1.11 + * by Oracle in the LICENSE file that accompanied this code.
1.12 + *
1.13 + * This code is distributed in the hope that it will be useful, but WITHOUT
1.14 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1.15 + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1.16 + * version 2 for more details (a copy is included in the LICENSE file that
1.17 + * accompanied this code).
1.18 + *
1.19 + * You should have received a copy of the GNU General Public License version
1.20 + * 2 along with this work; if not, write to the Free Software Foundation,
1.21 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
1.22 + *
1.23 + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
1.24 + * or visit www.oracle.com if you need additional information or have any
1.25 + * questions.
1.26 + */
1.27 +
1.28 +/*
1.29 + * This file is available under and governed by the GNU General Public
1.30 + * License version 2 only, as published by the Free Software Foundation.
1.31 + * However, the following notice accompanied the original version of this
1.32 + * file:
1.33 + *
1.34 + * Written by Doug Lea with assistance from members of JCP JSR-166
1.35 + * Expert Group and released to the public domain, as explained at
1.36 + * http://creativecommons.org/publicdomain/zero/1.0/
1.37 + */
1.38 +
1.39 +package java.util.concurrent.locks;
1.40 +import java.util.concurrent.*;
1.41 +import java.util.Date;
1.42 +
1.43 +/**
1.44 + * {@code Condition} factors out the {@code Object} monitor
1.45 + * methods ({@link Object#wait() wait}, {@link Object#notify notify}
1.46 + * and {@link Object#notifyAll notifyAll}) into distinct objects to
1.47 + * give the effect of having multiple wait-sets per object, by
1.48 + * combining them with the use of arbitrary {@link Lock} implementations.
1.49 + * Where a {@code Lock} replaces the use of {@code synchronized} methods
1.50 + * and statements, a {@code Condition} replaces the use of the Object
1.51 + * monitor methods.
1.52 + *
1.53 + * <p>Conditions (also known as <em>condition queues</em> or
1.54 + * <em>condition variables</em>) provide a means for one thread to
1.55 + * suspend execution (to "wait") until notified by another
1.56 + * thread that some state condition may now be true. Because access
1.57 + * to this shared state information occurs in different threads, it
1.58 + * must be protected, so a lock of some form is associated with the
1.59 + * condition. The key property that waiting for a condition provides
1.60 + * is that it <em>atomically</em> releases the associated lock and
1.61 + * suspends the current thread, just like {@code Object.wait}.
1.62 + *
1.63 + * <p>A {@code Condition} instance is intrinsically bound to a lock.
1.64 + * To obtain a {@code Condition} instance for a particular {@link Lock}
1.65 + * instance use its {@link Lock#newCondition newCondition()} method.
1.66 + *
1.67 + * <p>As an example, suppose we have a bounded buffer which supports
1.68 + * {@code put} and {@code take} methods. If a
1.69 + * {@code take} is attempted on an empty buffer, then the thread will block
1.70 + * until an item becomes available; if a {@code put} is attempted on a
1.71 + * full buffer, then the thread will block until a space becomes available.
1.72 + * We would like to keep waiting {@code put} threads and {@code take}
1.73 + * threads in separate wait-sets so that we can use the optimization of
1.74 + * only notifying a single thread at a time when items or spaces become
1.75 + * available in the buffer. This can be achieved using two
1.76 + * {@link Condition} instances.
1.77 + * <pre>
1.78 + * class BoundedBuffer {
1.79 + * <b>final Lock lock = new ReentrantLock();</b>
1.80 + * final Condition notFull = <b>lock.newCondition(); </b>
1.81 + * final Condition notEmpty = <b>lock.newCondition(); </b>
1.82 + *
1.83 + * final Object[] items = new Object[100];
1.84 + * int putptr, takeptr, count;
1.85 + *
1.86 + * public void put(Object x) throws InterruptedException {
1.87 + * <b>lock.lock();
1.88 + * try {</b>
1.89 + * while (count == items.length)
1.90 + * <b>notFull.await();</b>
1.91 + * items[putptr] = x;
1.92 + * if (++putptr == items.length) putptr = 0;
1.93 + * ++count;
1.94 + * <b>notEmpty.signal();</b>
1.95 + * <b>} finally {
1.96 + * lock.unlock();
1.97 + * }</b>
1.98 + * }
1.99 + *
1.100 + * public Object take() throws InterruptedException {
1.101 + * <b>lock.lock();
1.102 + * try {</b>
1.103 + * while (count == 0)
1.104 + * <b>notEmpty.await();</b>
1.105 + * Object x = items[takeptr];
1.106 + * if (++takeptr == items.length) takeptr = 0;
1.107 + * --count;
1.108 + * <b>notFull.signal();</b>
1.109 + * return x;
1.110 + * <b>} finally {
1.111 + * lock.unlock();
1.112 + * }</b>
1.113 + * }
1.114 + * }
1.115 + * </pre>
1.116 + *
1.117 + * (The {@link java.util.concurrent.ArrayBlockingQueue} class provides
1.118 + * this functionality, so there is no reason to implement this
1.119 + * sample usage class.)
1.120 + *
1.121 + * <p>A {@code Condition} implementation can provide behavior and semantics
1.122 + * that is
1.123 + * different from that of the {@code Object} monitor methods, such as
1.124 + * guaranteed ordering for notifications, or not requiring a lock to be held
1.125 + * when performing notifications.
1.126 + * If an implementation provides such specialized semantics then the
1.127 + * implementation must document those semantics.
1.128 + *
1.129 + * <p>Note that {@code Condition} instances are just normal objects and can
1.130 + * themselves be used as the target in a {@code synchronized} statement,
1.131 + * and can have their own monitor {@link Object#wait wait} and
1.132 + * {@link Object#notify notification} methods invoked.
1.133 + * Acquiring the monitor lock of a {@code Condition} instance, or using its
1.134 + * monitor methods, has no specified relationship with acquiring the
1.135 + * {@link Lock} associated with that {@code Condition} or the use of its
1.136 + * {@linkplain #await waiting} and {@linkplain #signal signalling} methods.
1.137 + * It is recommended that to avoid confusion you never use {@code Condition}
1.138 + * instances in this way, except perhaps within their own implementation.
1.139 + *
1.140 + * <p>Except where noted, passing a {@code null} value for any parameter
1.141 + * will result in a {@link NullPointerException} being thrown.
1.142 + *
1.143 + * <h3>Implementation Considerations</h3>
1.144 + *
1.145 + * <p>When waiting upon a {@code Condition}, a "<em>spurious
1.146 + * wakeup</em>" is permitted to occur, in
1.147 + * general, as a concession to the underlying platform semantics.
1.148 + * This has little practical impact on most application programs as a
1.149 + * {@code Condition} should always be waited upon in a loop, testing
1.150 + * the state predicate that is being waited for. An implementation is
1.151 + * free to remove the possibility of spurious wakeups but it is
1.152 + * recommended that applications programmers always assume that they can
1.153 + * occur and so always wait in a loop.
1.154 + *
1.155 + * <p>The three forms of condition waiting
1.156 + * (interruptible, non-interruptible, and timed) may differ in their ease of
1.157 + * implementation on some platforms and in their performance characteristics.
1.158 + * In particular, it may be difficult to provide these features and maintain
1.159 + * specific semantics such as ordering guarantees.
1.160 + * Further, the ability to interrupt the actual suspension of the thread may
1.161 + * not always be feasible to implement on all platforms.
1.162 + *
1.163 + * <p>Consequently, an implementation is not required to define exactly the
1.164 + * same guarantees or semantics for all three forms of waiting, nor is it
1.165 + * required to support interruption of the actual suspension of the thread.
1.166 + *
1.167 + * <p>An implementation is required to
1.168 + * clearly document the semantics and guarantees provided by each of the
1.169 + * waiting methods, and when an implementation does support interruption of
1.170 + * thread suspension then it must obey the interruption semantics as defined
1.171 + * in this interface.
1.172 + *
1.173 + * <p>As interruption generally implies cancellation, and checks for
1.174 + * interruption are often infrequent, an implementation can favor responding
1.175 + * to an interrupt over normal method return. This is true even if it can be
1.176 + * shown that the interrupt occurred after another action that may have
1.177 + * unblocked the thread. An implementation should document this behavior.
1.178 + *
1.179 + * @since 1.5
1.180 + * @author Doug Lea
1.181 + */
1.182 +public interface Condition {
1.183 +
1.184 + /**
1.185 + * Causes the current thread to wait until it is signalled or
1.186 + * {@linkplain Thread#interrupt interrupted}.
1.187 + *
1.188 + * <p>The lock associated with this {@code Condition} is atomically
1.189 + * released and the current thread becomes disabled for thread scheduling
1.190 + * purposes and lies dormant until <em>one</em> of four things happens:
1.191 + * <ul>
1.192 + * <li>Some other thread invokes the {@link #signal} method for this
1.193 + * {@code Condition} and the current thread happens to be chosen as the
1.194 + * thread to be awakened; or
1.195 + * <li>Some other thread invokes the {@link #signalAll} method for this
1.196 + * {@code Condition}; or
1.197 + * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
1.198 + * current thread, and interruption of thread suspension is supported; or
1.199 + * <li>A "<em>spurious wakeup</em>" occurs.
1.200 + * </ul>
1.201 + *
1.202 + * <p>In all cases, before this method can return the current thread must
1.203 + * re-acquire the lock associated with this condition. When the
1.204 + * thread returns it is <em>guaranteed</em> to hold this lock.
1.205 + *
1.206 + * <p>If the current thread:
1.207 + * <ul>
1.208 + * <li>has its interrupted status set on entry to this method; or
1.209 + * <li>is {@linkplain Thread#interrupt interrupted} while waiting
1.210 + * and interruption of thread suspension is supported,
1.211 + * </ul>
1.212 + * then {@link InterruptedException} is thrown and the current thread's
1.213 + * interrupted status is cleared. It is not specified, in the first
1.214 + * case, whether or not the test for interruption occurs before the lock
1.215 + * is released.
1.216 + *
1.217 + * <p><b>Implementation Considerations</b>
1.218 + *
1.219 + * <p>The current thread is assumed to hold the lock associated with this
1.220 + * {@code Condition} when this method is called.
1.221 + * It is up to the implementation to determine if this is
1.222 + * the case and if not, how to respond. Typically, an exception will be
1.223 + * thrown (such as {@link IllegalMonitorStateException}) and the
1.224 + * implementation must document that fact.
1.225 + *
1.226 + * <p>An implementation can favor responding to an interrupt over normal
1.227 + * method return in response to a signal. In that case the implementation
1.228 + * must ensure that the signal is redirected to another waiting thread, if
1.229 + * there is one.
1.230 + *
1.231 + * @throws InterruptedException if the current thread is interrupted
1.232 + * (and interruption of thread suspension is supported)
1.233 + */
1.234 + void await() throws InterruptedException;
1.235 +
1.236 + /**
1.237 + * Causes the current thread to wait until it is signalled.
1.238 + *
1.239 + * <p>The lock associated with this condition is atomically
1.240 + * released and the current thread becomes disabled for thread scheduling
1.241 + * purposes and lies dormant until <em>one</em> of three things happens:
1.242 + * <ul>
1.243 + * <li>Some other thread invokes the {@link #signal} method for this
1.244 + * {@code Condition} and the current thread happens to be chosen as the
1.245 + * thread to be awakened; or
1.246 + * <li>Some other thread invokes the {@link #signalAll} method for this
1.247 + * {@code Condition}; or
1.248 + * <li>A "<em>spurious wakeup</em>" occurs.
1.249 + * </ul>
1.250 + *
1.251 + * <p>In all cases, before this method can return the current thread must
1.252 + * re-acquire the lock associated with this condition. When the
1.253 + * thread returns it is <em>guaranteed</em> to hold this lock.
1.254 + *
1.255 + * <p>If the current thread's interrupted status is set when it enters
1.256 + * this method, or it is {@linkplain Thread#interrupt interrupted}
1.257 + * while waiting, it will continue to wait until signalled. When it finally
1.258 + * returns from this method its interrupted status will still
1.259 + * be set.
1.260 + *
1.261 + * <p><b>Implementation Considerations</b>
1.262 + *
1.263 + * <p>The current thread is assumed to hold the lock associated with this
1.264 + * {@code Condition} when this method is called.
1.265 + * It is up to the implementation to determine if this is
1.266 + * the case and if not, how to respond. Typically, an exception will be
1.267 + * thrown (such as {@link IllegalMonitorStateException}) and the
1.268 + * implementation must document that fact.
1.269 + */
1.270 + void awaitUninterruptibly();
1.271 +
1.272 + /**
1.273 + * Causes the current thread to wait until it is signalled or interrupted,
1.274 + * or the specified waiting time elapses.
1.275 + *
1.276 + * <p>The lock associated with this condition is atomically
1.277 + * released and the current thread becomes disabled for thread scheduling
1.278 + * purposes and lies dormant until <em>one</em> of five things happens:
1.279 + * <ul>
1.280 + * <li>Some other thread invokes the {@link #signal} method for this
1.281 + * {@code Condition} and the current thread happens to be chosen as the
1.282 + * thread to be awakened; or
1.283 + * <li>Some other thread invokes the {@link #signalAll} method for this
1.284 + * {@code Condition}; or
1.285 + * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
1.286 + * current thread, and interruption of thread suspension is supported; or
1.287 + * <li>The specified waiting time elapses; or
1.288 + * <li>A "<em>spurious wakeup</em>" occurs.
1.289 + * </ul>
1.290 + *
1.291 + * <p>In all cases, before this method can return the current thread must
1.292 + * re-acquire the lock associated with this condition. When the
1.293 + * thread returns it is <em>guaranteed</em> to hold this lock.
1.294 + *
1.295 + * <p>If the current thread:
1.296 + * <ul>
1.297 + * <li>has its interrupted status set on entry to this method; or
1.298 + * <li>is {@linkplain Thread#interrupt interrupted} while waiting
1.299 + * and interruption of thread suspension is supported,
1.300 + * </ul>
1.301 + * then {@link InterruptedException} is thrown and the current thread's
1.302 + * interrupted status is cleared. It is not specified, in the first
1.303 + * case, whether or not the test for interruption occurs before the lock
1.304 + * is released.
1.305 + *
1.306 + * <p>The method returns an estimate of the number of nanoseconds
1.307 + * remaining to wait given the supplied {@code nanosTimeout}
1.308 + * value upon return, or a value less than or equal to zero if it
1.309 + * timed out. This value can be used to determine whether and how
1.310 + * long to re-wait in cases where the wait returns but an awaited
1.311 + * condition still does not hold. Typical uses of this method take
1.312 + * the following form:
1.313 + *
1.314 + * <pre> {@code
1.315 + * boolean aMethod(long timeout, TimeUnit unit) {
1.316 + * long nanos = unit.toNanos(timeout);
1.317 + * lock.lock();
1.318 + * try {
1.319 + * while (!conditionBeingWaitedFor()) {
1.320 + * if (nanos <= 0L)
1.321 + * return false;
1.322 + * nanos = theCondition.awaitNanos(nanos);
1.323 + * }
1.324 + * // ...
1.325 + * } finally {
1.326 + * lock.unlock();
1.327 + * }
1.328 + * }}</pre>
1.329 + *
1.330 + * <p> Design note: This method requires a nanosecond argument so
1.331 + * as to avoid truncation errors in reporting remaining times.
1.332 + * Such precision loss would make it difficult for programmers to
1.333 + * ensure that total waiting times are not systematically shorter
1.334 + * than specified when re-waits occur.
1.335 + *
1.336 + * <p><b>Implementation Considerations</b>
1.337 + *
1.338 + * <p>The current thread is assumed to hold the lock associated with this
1.339 + * {@code Condition} when this method is called.
1.340 + * It is up to the implementation to determine if this is
1.341 + * the case and if not, how to respond. Typically, an exception will be
1.342 + * thrown (such as {@link IllegalMonitorStateException}) and the
1.343 + * implementation must document that fact.
1.344 + *
1.345 + * <p>An implementation can favor responding to an interrupt over normal
1.346 + * method return in response to a signal, or over indicating the elapse
1.347 + * of the specified waiting time. In either case the implementation
1.348 + * must ensure that the signal is redirected to another waiting thread, if
1.349 + * there is one.
1.350 + *
1.351 + * @param nanosTimeout the maximum time to wait, in nanoseconds
1.352 + * @return an estimate of the {@code nanosTimeout} value minus
1.353 + * the time spent waiting upon return from this method.
1.354 + * A positive value may be used as the argument to a
1.355 + * subsequent call to this method to finish waiting out
1.356 + * the desired time. A value less than or equal to zero
1.357 + * indicates that no time remains.
1.358 + * @throws InterruptedException if the current thread is interrupted
1.359 + * (and interruption of thread suspension is supported)
1.360 + */
1.361 + long awaitNanos(long nanosTimeout) throws InterruptedException;
1.362 +
1.363 + /**
1.364 + * Causes the current thread to wait until it is signalled or interrupted,
1.365 + * or the specified waiting time elapses. This method is behaviorally
1.366 + * equivalent to:<br>
1.367 + * <pre>
1.368 + * awaitNanos(unit.toNanos(time)) > 0
1.369 + * </pre>
1.370 + * @param time the maximum time to wait
1.371 + * @param unit the time unit of the {@code time} argument
1.372 + * @return {@code false} if the waiting time detectably elapsed
1.373 + * before return from the method, else {@code true}
1.374 + * @throws InterruptedException if the current thread is interrupted
1.375 + * (and interruption of thread suspension is supported)
1.376 + */
1.377 + boolean await(long time, TimeUnit unit) throws InterruptedException;
1.378 +
1.379 + /**
1.380 + * Causes the current thread to wait until it is signalled or interrupted,
1.381 + * or the specified deadline elapses.
1.382 + *
1.383 + * <p>The lock associated with this condition is atomically
1.384 + * released and the current thread becomes disabled for thread scheduling
1.385 + * purposes and lies dormant until <em>one</em> of five things happens:
1.386 + * <ul>
1.387 + * <li>Some other thread invokes the {@link #signal} method for this
1.388 + * {@code Condition} and the current thread happens to be chosen as the
1.389 + * thread to be awakened; or
1.390 + * <li>Some other thread invokes the {@link #signalAll} method for this
1.391 + * {@code Condition}; or
1.392 + * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
1.393 + * current thread, and interruption of thread suspension is supported; or
1.394 + * <li>The specified deadline elapses; or
1.395 + * <li>A "<em>spurious wakeup</em>" occurs.
1.396 + * </ul>
1.397 + *
1.398 + * <p>In all cases, before this method can return the current thread must
1.399 + * re-acquire the lock associated with this condition. When the
1.400 + * thread returns it is <em>guaranteed</em> to hold this lock.
1.401 + *
1.402 + *
1.403 + * <p>If the current thread:
1.404 + * <ul>
1.405 + * <li>has its interrupted status set on entry to this method; or
1.406 + * <li>is {@linkplain Thread#interrupt interrupted} while waiting
1.407 + * and interruption of thread suspension is supported,
1.408 + * </ul>
1.409 + * then {@link InterruptedException} is thrown and the current thread's
1.410 + * interrupted status is cleared. It is not specified, in the first
1.411 + * case, whether or not the test for interruption occurs before the lock
1.412 + * is released.
1.413 + *
1.414 + *
1.415 + * <p>The return value indicates whether the deadline has elapsed,
1.416 + * which can be used as follows:
1.417 + * <pre> {@code
1.418 + * boolean aMethod(Date deadline) {
1.419 + * boolean stillWaiting = true;
1.420 + * lock.lock();
1.421 + * try {
1.422 + * while (!conditionBeingWaitedFor()) {
1.423 + * if (!stillWaiting)
1.424 + * return false;
1.425 + * stillWaiting = theCondition.awaitUntil(deadline);
1.426 + * }
1.427 + * // ...
1.428 + * } finally {
1.429 + * lock.unlock();
1.430 + * }
1.431 + * }}</pre>
1.432 + *
1.433 + * <p><b>Implementation Considerations</b>
1.434 + *
1.435 + * <p>The current thread is assumed to hold the lock associated with this
1.436 + * {@code Condition} when this method is called.
1.437 + * It is up to the implementation to determine if this is
1.438 + * the case and if not, how to respond. Typically, an exception will be
1.439 + * thrown (such as {@link IllegalMonitorStateException}) and the
1.440 + * implementation must document that fact.
1.441 + *
1.442 + * <p>An implementation can favor responding to an interrupt over normal
1.443 + * method return in response to a signal, or over indicating the passing
1.444 + * of the specified deadline. In either case the implementation
1.445 + * must ensure that the signal is redirected to another waiting thread, if
1.446 + * there is one.
1.447 + *
1.448 + * @param deadline the absolute time to wait until
1.449 + * @return {@code false} if the deadline has elapsed upon return, else
1.450 + * {@code true}
1.451 + * @throws InterruptedException if the current thread is interrupted
1.452 + * (and interruption of thread suspension is supported)
1.453 + */
1.454 + boolean awaitUntil(Date deadline) throws InterruptedException;
1.455 +
1.456 + /**
1.457 + * Wakes up one waiting thread.
1.458 + *
1.459 + * <p>If any threads are waiting on this condition then one
1.460 + * is selected for waking up. That thread must then re-acquire the
1.461 + * lock before returning from {@code await}.
1.462 + *
1.463 + * <p><b>Implementation Considerations</b>
1.464 + *
1.465 + * <p>An implementation may (and typically does) require that the
1.466 + * current thread hold the lock associated with this {@code
1.467 + * Condition} when this method is called. Implementations must
1.468 + * document this precondition and any actions taken if the lock is
1.469 + * not held. Typically, an exception such as {@link
1.470 + * IllegalMonitorStateException} will be thrown.
1.471 + */
1.472 + void signal();
1.473 +
1.474 + /**
1.475 + * Wakes up all waiting threads.
1.476 + *
1.477 + * <p>If any threads are waiting on this condition then they are
1.478 + * all woken up. Each thread must re-acquire the lock before it can
1.479 + * return from {@code await}.
1.480 + *
1.481 + * <p><b>Implementation Considerations</b>
1.482 + *
1.483 + * <p>An implementation may (and typically does) require that the
1.484 + * current thread hold the lock associated with this {@code
1.485 + * Condition} when this method is called. Implementations must
1.486 + * document this precondition and any actions taken if the lock is
1.487 + * not held. Typically, an exception such as {@link
1.488 + * IllegalMonitorStateException} will be thrown.
1.489 + */
1.490 + void signalAll();
1.491 +}