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/Lock.java Sat Mar 19 10:46:31 2016 +0100
1.3 @@ -0,0 +1,356 @@
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.TimeUnit;
1.41 +
1.42 +/**
1.43 + * {@code Lock} implementations provide more extensive locking
1.44 + * operations than can be obtained using {@code synchronized} methods
1.45 + * and statements. They allow more flexible structuring, may have
1.46 + * quite different properties, and may support multiple associated
1.47 + * {@link Condition} objects.
1.48 + *
1.49 + * <p>A lock is a tool for controlling access to a shared resource by
1.50 + * multiple threads. Commonly, a lock provides exclusive access to a
1.51 + * shared resource: only one thread at a time can acquire the lock and
1.52 + * all access to the shared resource requires that the lock be
1.53 + * acquired first. However, some locks may allow concurrent access to
1.54 + * a shared resource, such as the read lock of a {@link ReadWriteLock}.
1.55 + *
1.56 + * <p>The use of {@code synchronized} methods or statements provides
1.57 + * access to the implicit monitor lock associated with every object, but
1.58 + * forces all lock acquisition and release to occur in a block-structured way:
1.59 + * when multiple locks are acquired they must be released in the opposite
1.60 + * order, and all locks must be released in the same lexical scope in which
1.61 + * they were acquired.
1.62 + *
1.63 + * <p>While the scoping mechanism for {@code synchronized} methods
1.64 + * and statements makes it much easier to program with monitor locks,
1.65 + * and helps avoid many common programming errors involving locks,
1.66 + * there are occasions where you need to work with locks in a more
1.67 + * flexible way. For example, some algorithms for traversing
1.68 + * concurrently accessed data structures require the use of
1.69 + * "hand-over-hand" or "chain locking": you
1.70 + * acquire the lock of node A, then node B, then release A and acquire
1.71 + * C, then release B and acquire D and so on. Implementations of the
1.72 + * {@code Lock} interface enable the use of such techniques by
1.73 + * allowing a lock to be acquired and released in different scopes,
1.74 + * and allowing multiple locks to be acquired and released in any
1.75 + * order.
1.76 + *
1.77 + * <p>With this increased flexibility comes additional
1.78 + * responsibility. The absence of block-structured locking removes the
1.79 + * automatic release of locks that occurs with {@code synchronized}
1.80 + * methods and statements. In most cases, the following idiom
1.81 + * should be used:
1.82 + *
1.83 + * <pre><tt> Lock l = ...;
1.84 + * l.lock();
1.85 + * try {
1.86 + * // access the resource protected by this lock
1.87 + * } finally {
1.88 + * l.unlock();
1.89 + * }
1.90 + * </tt></pre>
1.91 + *
1.92 + * When locking and unlocking occur in different scopes, care must be
1.93 + * taken to ensure that all code that is executed while the lock is
1.94 + * held is protected by try-finally or try-catch to ensure that the
1.95 + * lock is released when necessary.
1.96 + *
1.97 + * <p>{@code Lock} implementations provide additional functionality
1.98 + * over the use of {@code synchronized} methods and statements by
1.99 + * providing a non-blocking attempt to acquire a lock ({@link
1.100 + * #tryLock()}), an attempt to acquire the lock that can be
1.101 + * interrupted ({@link #lockInterruptibly}, and an attempt to acquire
1.102 + * the lock that can timeout ({@link #tryLock(long, TimeUnit)}).
1.103 + *
1.104 + * <p>A {@code Lock} class can also provide behavior and semantics
1.105 + * that is quite different from that of the implicit monitor lock,
1.106 + * such as guaranteed ordering, non-reentrant usage, or deadlock
1.107 + * detection. If an implementation provides such specialized semantics
1.108 + * then the implementation must document those semantics.
1.109 + *
1.110 + * <p>Note that {@code Lock} instances are just normal objects and can
1.111 + * themselves be used as the target in a {@code synchronized} statement.
1.112 + * Acquiring the
1.113 + * monitor lock of a {@code Lock} instance has no specified relationship
1.114 + * with invoking any of the {@link #lock} methods of that instance.
1.115 + * It is recommended that to avoid confusion you never use {@code Lock}
1.116 + * instances in this way, except within their own implementation.
1.117 + *
1.118 + * <p>Except where noted, passing a {@code null} value for any
1.119 + * parameter will result in a {@link NullPointerException} being
1.120 + * thrown.
1.121 + *
1.122 + * <h3>Memory Synchronization</h3>
1.123 + *
1.124 + * <p>All {@code Lock} implementations <em>must</em> enforce the same
1.125 + * memory synchronization semantics as provided by the built-in monitor
1.126 + * lock, as described in section 17.4 of
1.127 + * <cite>The Java™ Language Specification</cite>:
1.128 + * <ul>
1.129 + * <li>A successful {@code lock} operation has the same memory
1.130 + * synchronization effects as a successful <em>Lock</em> action.
1.131 + * <li>A successful {@code unlock} operation has the same
1.132 + * memory synchronization effects as a successful <em>Unlock</em> action.
1.133 + * </ul>
1.134 + *
1.135 + * Unsuccessful locking and unlocking operations, and reentrant
1.136 + * locking/unlocking operations, do not require any memory
1.137 + * synchronization effects.
1.138 + *
1.139 + * <h3>Implementation Considerations</h3>
1.140 + *
1.141 + * <p> The three forms of lock acquisition (interruptible,
1.142 + * non-interruptible, and timed) may differ in their performance
1.143 + * characteristics, ordering guarantees, or other implementation
1.144 + * qualities. Further, the ability to interrupt the <em>ongoing</em>
1.145 + * acquisition of a lock may not be available in a given {@code Lock}
1.146 + * class. Consequently, an implementation is not required to define
1.147 + * exactly the same guarantees or semantics for all three forms of
1.148 + * lock acquisition, nor is it required to support interruption of an
1.149 + * ongoing lock acquisition. An implementation is required to clearly
1.150 + * document the semantics and guarantees provided by each of the
1.151 + * locking methods. It must also obey the interruption semantics as
1.152 + * defined in this interface, to the extent that interruption of lock
1.153 + * acquisition is supported: which is either totally, or only on
1.154 + * method entry.
1.155 + *
1.156 + * <p>As interruption generally implies cancellation, and checks for
1.157 + * interruption are often infrequent, an implementation can favor responding
1.158 + * to an interrupt over normal method return. This is true even if it can be
1.159 + * shown that the interrupt occurred after another action may have unblocked
1.160 + * the thread. An implementation should document this behavior.
1.161 + *
1.162 + * @see ReentrantLock
1.163 + * @see Condition
1.164 + * @see ReadWriteLock
1.165 + *
1.166 + * @since 1.5
1.167 + * @author Doug Lea
1.168 + */
1.169 +public interface Lock {
1.170 +
1.171 + /**
1.172 + * Acquires the lock.
1.173 + *
1.174 + * <p>If the lock is not available then the current thread becomes
1.175 + * disabled for thread scheduling purposes and lies dormant until the
1.176 + * lock has been acquired.
1.177 + *
1.178 + * <p><b>Implementation Considerations</b>
1.179 + *
1.180 + * <p>A {@code Lock} implementation may be able to detect erroneous use
1.181 + * of the lock, such as an invocation that would cause deadlock, and
1.182 + * may throw an (unchecked) exception in such circumstances. The
1.183 + * circumstances and the exception type must be documented by that
1.184 + * {@code Lock} implementation.
1.185 + */
1.186 + void lock();
1.187 +
1.188 + /**
1.189 + * Acquires the lock unless the current thread is
1.190 + * {@linkplain Thread#interrupt interrupted}.
1.191 + *
1.192 + * <p>Acquires the lock if it is available and returns immediately.
1.193 + *
1.194 + * <p>If the lock is not available then the current thread becomes
1.195 + * disabled for thread scheduling purposes and lies dormant until
1.196 + * one of two things happens:
1.197 + *
1.198 + * <ul>
1.199 + * <li>The lock is acquired by the current thread; or
1.200 + * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
1.201 + * current thread, and interruption of lock acquisition is supported.
1.202 + * </ul>
1.203 + *
1.204 + * <p>If the current thread:
1.205 + * <ul>
1.206 + * <li>has its interrupted status set on entry to this method; or
1.207 + * <li>is {@linkplain Thread#interrupt interrupted} while acquiring the
1.208 + * lock, and interruption of lock acquisition is supported,
1.209 + * </ul>
1.210 + * then {@link InterruptedException} is thrown and the current thread's
1.211 + * interrupted status is cleared.
1.212 + *
1.213 + * <p><b>Implementation Considerations</b>
1.214 + *
1.215 + * <p>The ability to interrupt a lock acquisition in some
1.216 + * implementations may not be possible, and if possible may be an
1.217 + * expensive operation. The programmer should be aware that this
1.218 + * may be the case. An implementation should document when this is
1.219 + * the case.
1.220 + *
1.221 + * <p>An implementation can favor responding to an interrupt over
1.222 + * normal method return.
1.223 + *
1.224 + * <p>A {@code Lock} implementation may be able to detect
1.225 + * erroneous use of the lock, such as an invocation that would
1.226 + * cause deadlock, and may throw an (unchecked) exception in such
1.227 + * circumstances. The circumstances and the exception type must
1.228 + * be documented by that {@code Lock} implementation.
1.229 + *
1.230 + * @throws InterruptedException if the current thread is
1.231 + * interrupted while acquiring the lock (and interruption
1.232 + * of lock acquisition is supported).
1.233 + */
1.234 + void lockInterruptibly() throws InterruptedException;
1.235 +
1.236 + /**
1.237 + * Acquires the lock only if it is free at the time of invocation.
1.238 + *
1.239 + * <p>Acquires the lock if it is available and returns immediately
1.240 + * with the value {@code true}.
1.241 + * If the lock is not available then this method will return
1.242 + * immediately with the value {@code false}.
1.243 + *
1.244 + * <p>A typical usage idiom for this method would be:
1.245 + * <pre>
1.246 + * Lock lock = ...;
1.247 + * if (lock.tryLock()) {
1.248 + * try {
1.249 + * // manipulate protected state
1.250 + * } finally {
1.251 + * lock.unlock();
1.252 + * }
1.253 + * } else {
1.254 + * // perform alternative actions
1.255 + * }
1.256 + * </pre>
1.257 + * This usage ensures that the lock is unlocked if it was acquired, and
1.258 + * doesn't try to unlock if the lock was not acquired.
1.259 + *
1.260 + * @return {@code true} if the lock was acquired and
1.261 + * {@code false} otherwise
1.262 + */
1.263 + boolean tryLock();
1.264 +
1.265 + /**
1.266 + * Acquires the lock if it is free within the given waiting time and the
1.267 + * current thread has not been {@linkplain Thread#interrupt interrupted}.
1.268 + *
1.269 + * <p>If the lock is available this method returns immediately
1.270 + * with the value {@code true}.
1.271 + * If the lock is not available then
1.272 + * the current thread becomes disabled for thread scheduling
1.273 + * purposes and lies dormant until one of three things happens:
1.274 + * <ul>
1.275 + * <li>The lock is acquired by the current thread; or
1.276 + * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
1.277 + * current thread, and interruption of lock acquisition is supported; or
1.278 + * <li>The specified waiting time elapses
1.279 + * </ul>
1.280 + *
1.281 + * <p>If the lock is acquired then the value {@code true} is returned.
1.282 + *
1.283 + * <p>If the current thread:
1.284 + * <ul>
1.285 + * <li>has its interrupted status set on entry to this method; or
1.286 + * <li>is {@linkplain Thread#interrupt interrupted} while acquiring
1.287 + * the lock, and interruption of lock acquisition is supported,
1.288 + * </ul>
1.289 + * then {@link InterruptedException} is thrown and the current thread's
1.290 + * interrupted status is cleared.
1.291 + *
1.292 + * <p>If the specified waiting time elapses then the value {@code false}
1.293 + * is returned.
1.294 + * If the time is
1.295 + * less than or equal to zero, the method will not wait at all.
1.296 + *
1.297 + * <p><b>Implementation Considerations</b>
1.298 + *
1.299 + * <p>The ability to interrupt a lock acquisition in some implementations
1.300 + * may not be possible, and if possible may
1.301 + * be an expensive operation.
1.302 + * The programmer should be aware that this may be the case. An
1.303 + * implementation should document when this is the case.
1.304 + *
1.305 + * <p>An implementation can favor responding to an interrupt over normal
1.306 + * method return, or reporting a timeout.
1.307 + *
1.308 + * <p>A {@code Lock} implementation may be able to detect
1.309 + * erroneous use of the lock, such as an invocation that would cause
1.310 + * deadlock, and may throw an (unchecked) exception in such circumstances.
1.311 + * The circumstances and the exception type must be documented by that
1.312 + * {@code Lock} implementation.
1.313 + *
1.314 + * @param time the maximum time to wait for the lock
1.315 + * @param unit the time unit of the {@code time} argument
1.316 + * @return {@code true} if the lock was acquired and {@code false}
1.317 + * if the waiting time elapsed before the lock was acquired
1.318 + *
1.319 + * @throws InterruptedException if the current thread is interrupted
1.320 + * while acquiring the lock (and interruption of lock
1.321 + * acquisition is supported)
1.322 + */
1.323 + boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
1.324 +
1.325 + /**
1.326 + * Releases the lock.
1.327 + *
1.328 + * <p><b>Implementation Considerations</b>
1.329 + *
1.330 + * <p>A {@code Lock} implementation will usually impose
1.331 + * restrictions on which thread can release a lock (typically only the
1.332 + * holder of the lock can release it) and may throw
1.333 + * an (unchecked) exception if the restriction is violated.
1.334 + * Any restrictions and the exception
1.335 + * type must be documented by that {@code Lock} implementation.
1.336 + */
1.337 + void unlock();
1.338 +
1.339 + /**
1.340 + * Returns a new {@link Condition} instance that is bound to this
1.341 + * {@code Lock} instance.
1.342 + *
1.343 + * <p>Before waiting on the condition the lock must be held by the
1.344 + * current thread.
1.345 + * A call to {@link Condition#await()} will atomically release the lock
1.346 + * before waiting and re-acquire the lock before the wait returns.
1.347 + *
1.348 + * <p><b>Implementation Considerations</b>
1.349 + *
1.350 + * <p>The exact operation of the {@link Condition} instance depends on
1.351 + * the {@code Lock} implementation and must be documented by that
1.352 + * implementation.
1.353 + *
1.354 + * @return A new {@link Condition} instance for this {@code Lock} instance
1.355 + * @throws UnsupportedOperationException if this {@code Lock}
1.356 + * implementation does not support conditions
1.357 + */
1.358 + Condition newCondition();
1.359 +}