001: /*
002: * Written by Doug Lea with assistance from members of JCP JSR-166
003: * Expert Group and released to the public domain, as explained at
004: * http://creativecommons.org/licenses/publicdomain
005: */
006:
007: package org.apache.beehive.netui.util.internal.concurrent;
008:
009: /**
010: * <tt>Lock</tt> implementations provide more extensive locking
011: * operations than can be obtained using <tt>synchronized</tt> methods
012: * and statements. They allow more flexible structuring, may have
013: * quite different properties, and may support multiple associated
014: * {@link Condition} objects.
015: *
016: * <p>A lock is a tool for controlling access to a shared resource by
017: * multiple threads. Commonly, a lock provides exclusive access to a
018: * shared resource: only one thread at a time can acquire the lock and
019: * all access to the shared resource requires that the lock be
020: * acquired first. However, some locks may allow concurrent access to
021: * a shared resource, such as the read lock of a {@link
022: * ReadWriteLock}.
023: *
024: * <p>The use of <tt>synchronized</tt> methods or statements provides
025: * access to the implicit monitor lock associated with every object, but
026: * forces all lock acquisition and release to occur in a block-structured way:
027: * when multiple locks are acquired they must be released in the opposite
028: * order, and all locks must be released in the same lexical scope in which
029: * they were acquired.
030: *
031: * <p>While the scoping mechanism for <tt>synchronized</tt> methods
032: * and statements makes it much easier to program with monitor locks,
033: * and helps avoid many common programming errors involving locks,
034: * there are occasions where you need to work with locks in a more
035: * flexible way. For example, some algorithms for traversing
036: * concurrently accessed data structures require the use of
037: * "hand-over-hand" or "chain locking": you
038: * acquire the lock of node A, then node B, then release A and acquire
039: * C, then release B and acquire D and so on. Implementations of the
040: * <tt>Lock</tt> interface enable the use of such techniques by
041: * allowing a lock to be acquired and released in different scopes,
042: * and allowing multiple locks to be acquired and released in any
043: * order.
044: *
045: * <p>With this increased flexibility comes additional
046: * responsibility. The absence of block-structured locking removes the
047: * automatic release of locks that occurs with <tt>synchronized</tt>
048: * methods and statements. In most cases, the following idiom
049: * should be used:
050: *
051: * <pre><tt> Lock l = ...;
052: * l.lock();
053: * try {
054: * // access the resource protected by this lock
055: * } finally {
056: * l.unlock();
057: * }
058: * </tt></pre>
059: *
060: * When locking and unlocking occur in different scopes, care must be
061: * taken to ensure that all code that is executed while the lock is
062: * held is protected by try-finally or try-catch to ensure that the
063: * lock is released when necessary.
064: *
065: * <p><tt>Lock</tt> implementations provide additional functionality
066: * over the use of <tt>synchronized</tt> methods and statements by
067: * providing a non-blocking attempt to acquire a lock ({@link
068: * #tryLock()}), an attempt to acquire the lock that can be
069: * interrupted ({@link #lockInterruptibly}, and an attempt to acquire
070: * the lock that can timeout ({@link #tryLock(long, TimeUnit)}).
071: *
072: * <p>A <tt>Lock</tt> class can also provide behavior and semantics
073: * that is quite different from that of the implicit monitor lock,
074: * such as guaranteed ordering, non-reentrant usage, or deadlock
075: * detection. If an implementation provides such specialized semantics
076: * then the implementation must document those semantics.
077: *
078: * <p>Note that <tt>Lock</tt> instances are just normal objects and can
079: * themselves be used as the target in a <tt>synchronized</tt> statement.
080: * Acquiring the
081: * monitor lock of a <tt>Lock</tt> instance has no specified relationship
082: * with invoking any of the {@link #lock} methods of that instance.
083: * It is recommended that to avoid confusion you never use <tt>Lock</tt>
084: * instances in this way, except within their own implementation.
085: *
086: * <p>Except where noted, passing a <tt>null</tt> value for any
087: * parameter will result in a {@link NullPointerException} being
088: * thrown.
089: *
090: * <h3>Memory Synchronization</h3>
091: * <p>All <tt>Lock</tt> implementations <em>must</em> enforce the same
092: * memory synchronization semantics as provided by the built-in monitor lock:
093: * <ul>
094: * <li>A successful lock operation acts like a successful
095: * <tt>monitorEnter</tt> action
096: * <li>A successful <tt>unlock</tt> operation acts like a successful
097: * <tt>monitorExit</tt> action
098: * </ul>
099: *
100: * Unsuccessful locking and unlocking operations, and reentrant
101: * locking/unlocking operations, do not require any memory
102: * synchronization effects.
103: *
104: * <h3>Implementation Considerations</h3>
105: *
106: * <p> The three forms of lock acquisition (interruptible,
107: * non-interruptible, and timed) may differ in their performance
108: * characteristics, ordering guarantees, or other implementation
109: * qualities. Further, the ability to interrupt the <em>ongoing</em>
110: * acquisition of a lock may not be available in a given <tt>Lock</tt>
111: * class. Consequently, an implementation is not required to define
112: * exactly the same guarantees or semantics for all three forms of
113: * lock acquisition, nor is it required to support interruption of an
114: * ongoing lock acquisition. An implementation is required to clearly
115: * document the semantics and guarantees provided by each of the
116: * locking methods. It must also obey the interruption semantics as
117: * defined in this interface, to the extent that interruption of lock
118: * acquisition is supported: which is either totally, or only on
119: * method entry.
120: *
121: * <p>As interruption generally implies cancellation, and checks for
122: * interruption are often infrequent, an implementation can favor responding
123: * to an interrupt over normal method return. This is true even if it can be
124: * shown that the interrupt occurred after another action may have unblocked
125: * the thread. An implementation should document this behavior.
126: *
127: *
128: * @see ReentrantLock
129: * @see Condition
130: * @see ReadWriteLock
131: *
132: * @since 1.5
133: * @author Doug Lea
134: *
135: **/
136: interface Lock {
137:
138: /**
139: * Acquires the lock.
140: * <p>If the lock is not available then
141: * the current thread becomes disabled for thread scheduling
142: * purposes and lies dormant until the lock has been acquired.
143: * <p><b>Implementation Considerations</b>
144: * <p>A <tt>Lock</tt> implementation may be able to detect
145: * erroneous use of the lock, such as an invocation that would cause
146: * deadlock, and may throw an (unchecked) exception in such circumstances.
147: * The circumstances and the exception type must be documented by that
148: * <tt>Lock</tt> implementation.
149: *
150: **/
151: void lock();
152:
153: /**
154: * Acquires the lock unless the current thread is
155: * {@link Thread#interrupt interrupted}.
156: * <p>Acquires the lock if it is available and returns immediately.
157: * <p>If the lock is not available then
158: * the current thread becomes disabled for thread scheduling
159: * purposes and lies dormant until one of two things happens:
160: * <ul>
161: * <li>The lock is acquired by the current thread; or
162: * <li>Some other thread {@link Thread#interrupt interrupts} the current
163: * thread, and interruption of lock acquisition is supported.
164: * </ul>
165: * <p>If the current thread:
166: * <ul>
167: * <li>has its interrupted status set on entry to this method; or
168: * <li>is {@link Thread#interrupt interrupted} while acquiring
169: * the lock, and interruption of lock acquisition is supported,
170: * </ul>
171: * then {@link InterruptedException} is thrown and the current thread's
172: * interrupted status is cleared.
173: *
174: * <p><b>Implementation Considerations</b>
175: *
176: * <p>The ability to interrupt a lock acquisition in some
177: * implementations may not be possible, and if possible may be an
178: * expensive operation. The programmer should be aware that this
179: * may be the case. An implementation should document when this is
180: * the case.
181: *
182: * <p>An implementation can favor responding to an interrupt over
183: * normal method return.
184: *
185: * <p>A <tt>Lock</tt> implementation may be able to detect
186: * erroneous use of the lock, such as an invocation that would
187: * cause deadlock, and may throw an (unchecked) exception in such
188: * circumstances. The circumstances and the exception type must
189: * be documented by that <tt>Lock</tt> implementation.
190: *
191: * @throws InterruptedException if the current thread is interrupted
192: * while acquiring the lock (and interruption of lock acquisition is
193: * supported).
194: *
195: * @see Thread#interrupt
196: *
197: **/
198: void lockInterruptibly() throws InterruptedException;
199:
200: /**
201: * Acquires the lock only if it is free at the time of invocation.
202: * <p>Acquires the lock if it is available and returns immediately
203: * with the value <tt>true</tt>.
204: * If the lock is not available then this method will return
205: * immediately with the value <tt>false</tt>.
206: * <p>A typical usage idiom for this method would be:
207: * <pre>
208: * Lock lock = ...;
209: * if (lock.tryLock()) {
210: * try {
211: * // manipulate protected state
212: * } finally {
213: * lock.unlock();
214: * }
215: * } else {
216: * // perform alternative actions
217: * }
218: * </pre>
219: * This usage ensures that the lock is unlocked if it was acquired, and
220: * doesn't try to unlock if the lock was not acquired.
221: *
222: * @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
223: * otherwise.
224: **/
225: boolean tryLock();
226:
227: /**
228: * Acquires the lock if it is free within the given waiting time and the
229: * current thread has not been {@link Thread#interrupt interrupted}.
230: *
231: * <p>If the lock is available this method returns immediately
232: * with the value <tt>true</tt>.
233: * If the lock is not available then
234: * the current thread becomes disabled for thread scheduling
235: * purposes and lies dormant until one of three things happens:
236: * <ul>
237: * <li>The lock is acquired by the current thread; or
238: * <li>Some other thread {@link Thread#interrupt interrupts} the current
239: * thread, and interruption of lock acquisition is supported; or
240: * <li>The specified waiting time elapses
241: * </ul>
242: * <p>If the lock is acquired then the value <tt>true</tt> is returned.
243: * <p>If the current thread:
244: * <ul>
245: * <li>has its interrupted status set on entry to this method; or
246: * <li>is {@link Thread#interrupt interrupted} while acquiring
247: * the lock, and interruption of lock acquisition is supported,
248: * </ul>
249: * then {@link InterruptedException} is thrown and the current thread's
250: * interrupted status is cleared.
251: * <p>If the specified waiting time elapses then the value <tt>false</tt>
252: * is returned.
253: * If the time is
254: * less than or equal to zero, the method will not wait at all.
255: *
256: * <p><b>Implementation Considerations</b>
257: * <p>The ability to interrupt a lock acquisition in some implementations
258: * may not be possible, and if possible may
259: * be an expensive operation.
260: * The programmer should be aware that this may be the case. An
261: * implementation should document when this is the case.
262: * <p>An implementation can favor responding to an interrupt over normal
263: * method return, or reporting a timeout.
264: * <p>A <tt>Lock</tt> implementation may be able to detect
265: * erroneous use of the lock, such as an invocation that would cause
266: * deadlock, and may throw an (unchecked) exception in such circumstances.
267: * The circumstances and the exception type must be documented by that
268: * <tt>Lock</tt> implementation.
269: *
270: * @param time the maximum time to wait for the lock
271: * @param unit the time unit of the <tt>time</tt> argument.
272: * @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
273: * if the waiting time elapsed before the lock was acquired.
274: *
275: * @throws InterruptedException if the current thread is interrupted
276: * while acquiring the lock (and interruption of lock acquisition is
277: * supported).
278: *
279: * @see Thread#interrupt
280: *
281: **/
282: boolean tryLock(long time, TimeUnit unit)
283: throws InterruptedException;
284:
285: /**
286: * Releases the lock.
287: * <p><b>Implementation Considerations</b>
288: * <p>A <tt>Lock</tt> implementation will usually impose
289: * restrictions on which thread can release a lock (typically only the
290: * holder of the lock can release it) and may throw
291: * an (unchecked) exception if the restriction is violated.
292: * Any restrictions and the exception
293: * type must be documented by that <tt>Lock</tt> implementation.
294: **/
295: void unlock();
296:
297: /**
298: * Returns a new {@link Condition} instance that is bound to this
299: * <tt>Lock</tt> instance.
300: * <p>Before waiting on the condition the lock must be held by the
301: * current thread.
302: * A call to {@link Condition#await()} will atomically release the lock
303: * before waiting and re-acquire the lock before the wait returns.
304: * <p><b>Implementation Considerations</b>
305: * <p>The exact operation of the {@link Condition} instance depends on the
306: * <tt>Lock</tt> implementation and must be documented by that
307: * implementation.
308: *
309: * @return A new {@link Condition} instance for this <tt>Lock</tt>
310: * instance.
311: * @throws UnsupportedOperationException if this <tt>Lock</tt>
312: * implementation does not support conditions.
313: **/
314: Condition newCondition();
315:
316: }
|