Lock


1   /*
2    * Written by Doug Lea with assistance from members of JCP JSR-166
3    * Expert Group and released to the public domain, as explained at
4    * http://creativecommons.org/licenses/publicdomain
5    */
6   
7   package org.apache.beehive.netui.util.internal.concurrent;
8   
9   /**
10   * <tt>Lock</tt> implementations provide more extensive locking
11   * operations than can be obtained using <tt>synchronized</tt> methods
12   * and statements.  They allow more flexible structuring, may have
13   * quite different properties, and may support multiple associated
14   * {@link Condition} objects.
15   *
16   * <p>A lock is a tool for controlling access to a shared resource by
17   * multiple threads. Commonly, a lock provides exclusive access to a
18   * shared resource: only one thread at a time can acquire the lock and
19   * all access to the shared resource requires that the lock be
20   * acquired first. However, some locks may allow concurrent access to
21   * a shared resource, such as the read lock of a {@link
22   * ReadWriteLock}.
23   *
24   * <p>The use of <tt>synchronized</tt> methods or statements provides
25   * access to the implicit monitor lock associated with every object, but
26   * forces all lock acquisition and release to occur in a block-structured way:
27   * when multiple locks are acquired they must be released in the opposite
28   * order, and all locks must be released in the same lexical scope in which
29   * they were acquired.
30   *
31   * <p>While the scoping mechanism for <tt>synchronized</tt> methods
32   * and statements makes it much easier to program with monitor locks,
33   * and helps avoid many common programming errors involving locks,
34   * there are occasions where you need to work with locks in a more
35   * flexible way. For example, some algorithms for traversing
36   * concurrently accessed data structures require the use of
37   * &quot;hand-over-hand&quot; or &quot;chain locking&quot;: you
38   * acquire the lock of node A, then node B, then release A and acquire
39   * C, then release B and acquire D and so on.  Implementations of the
40   * <tt>Lock</tt> interface enable the use of such techniques by
41   * allowing a lock to be acquired and released in different scopes,
42   * and allowing multiple locks to be acquired and released in any
43   * order.
44   *
45   * <p>With this increased flexibility comes additional
46   * responsibility. The absence of block-structured locking removes the
47   * automatic release of locks that occurs with <tt>synchronized</tt>
48   * methods and statements. In most cases, the following idiom
49   * should be used:
50   *
51   * <pre><tt>     Lock l = ...;
52   *     l.lock();
53   *     try {
54   *         // access the resource protected by this lock
55   *     } finally {
56   *         l.unlock();
57   *     }
58   * </tt></pre>
59   *
60   * When locking and unlocking occur in different scopes, care must be
61   * taken to ensure that all code that is executed while the lock is
62   * held is protected by try-finally or try-catch to ensure that the
63   * lock is released when necessary.
64   *
65   * <p><tt>Lock</tt> implementations provide additional functionality
66   * over the use of <tt>synchronized</tt> methods and statements by
67   * providing a non-blocking attempt to acquire a lock ({@link
68   * #tryLock()}), an attempt to acquire the lock that can be
69   * interrupted ({@link #lockInterruptibly}, and an attempt to acquire
70   * the lock that can timeout ({@link #tryLock(long, TimeUnit)}).
71   *
72   * <p>A <tt>Lock</tt> class can also provide behavior and semantics
73   * that is quite different from that of the implicit monitor lock,
74   * such as guaranteed ordering, non-reentrant usage, or deadlock
75   * detection. If an implementation provides such specialized semantics
76   * then the implementation must document those semantics.
77   *
78   * <p>Note that <tt>Lock</tt> instances are just normal objects and can
79   * themselves be used as the target in a <tt>synchronized</tt> statement.
80   * Acquiring the
81   * monitor lock of a <tt>Lock</tt> instance has no specified relationship
82   * with invoking any of the {@link #lock} methods of that instance.
83   * It is recommended that to avoid confusion you never use <tt>Lock</tt>
84   * instances in this way, except within their own implementation.
85   *
86   * <p>Except where noted, passing a <tt>null</tt> value for any
87   * parameter will result in a {@link NullPointerException} being
88   * thrown.
89   *
90   * <h3>Memory Synchronization</h3>
91   * <p>All <tt>Lock</tt> implementations <em>must</em> enforce the same
92   * memory synchronization semantics as provided by the built-in monitor lock:
93   * <ul>
94   * <li>A successful lock operation acts like a successful
95   * <tt>monitorEnter</tt> action
96   * <li>A successful <tt>unlock</tt> operation acts like a successful
97   * <tt>monitorExit</tt> action
98   * </ul>
99   *
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     /**
202      * Acquires the lock only if it is free at the time of invocation.
203      * <p>Acquires the lock if it is available and returns immediately
204      * with the value <tt>true</tt>.
205      * If the lock is not available then this method will return
206      * immediately with the value <tt>false</tt>.
207      * <p>A typical usage idiom for this method would be:
208      * <pre>
209      *      Lock lock = ...;
210      *      if (lock.tryLock()) {
211      *          try {
212      *              // manipulate protected state
213      *          } finally {
214      *              lock.unlock();
215      *          }
216      *      } else {
217      *          // perform alternative actions
218      *      }
219      * </pre>
220      * This usage ensures that the lock is unlocked if it was acquired, and
221      * doesn't try to unlock if the lock was not acquired.
222      *
223      * @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
224      * otherwise.
225      **/
226     boolean tryLock();
227 
228     /**
229      * Acquires the lock if it is free within the given waiting time and the
230      * current thread has not been {@link Thread#interrupt interrupted}.
231      *
232      * <p>If the lock is available this method returns immediately
233      * with the value <tt>true</tt>.
234      * If the lock is not available then
235      * the current thread becomes disabled for thread scheduling
236      * purposes and lies dormant until one of three things happens:
237      * <ul>
238      * <li>The lock is acquired by the current thread; or
239      * <li>Some other thread {@link Thread#interrupt interrupts} the current
240      * thread, and interruption of lock acquisition is supported; or
241      * <li>The specified waiting time elapses
242      * </ul>
243      * <p>If the lock is acquired then the value <tt>true</tt> is returned.
244      * <p>If the current thread:
245      * <ul>
246      * <li>has its interrupted status set on entry to this method; or
247      * <li>is {@link Thread#interrupt interrupted} while acquiring
248      * the lock, and interruption of lock acquisition is supported,
249      * </ul>
250      * then {@link InterruptedException} is thrown and the current thread's
251      * interrupted status is cleared.
252      * <p>If the specified waiting time elapses then the value <tt>false</tt>
253      * is returned.
254      * If the time is
255      * less than or equal to zero, the method will not wait at all.
256      *
257      * <p><b>Implementation Considerations</b>
258      * <p>The ability to interrupt a lock acquisition in some implementations
259      * may not be possible, and if possible may
260      * be an expensive operation.
261      * The programmer should be aware that this may be the case. An
262      * implementation should document when this is the case.
263      * <p>An implementation can favor responding to an interrupt over normal
264      * method return, or reporting a timeout.
265      * <p>A <tt>Lock</tt> implementation may be able to detect
266      * erroneous use of the lock, such as an invocation that would cause
267      * deadlock, and may throw an (unchecked) exception in such circumstances.
268      * The circumstances and the exception type must be documented by that
269      * <tt>Lock</tt> implementation.
270      *
271      * @param time the maximum time to wait for the lock
272      * @param unit the time unit of the <tt>time</tt> argument.
273      * @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
274      * if the waiting time elapsed before the lock was acquired.
275      *
276      * @throws InterruptedException if the current thread is interrupted
277      * while acquiring the lock (and interruption of lock acquisition is
278      * supported).
279      *
280      * @see Thread#interrupt
281      *
282      **/
283     boolean tryLock(long time, TimeUnit unit) 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 }
317 
318 
319 
320 
321 
322 
323 
324 
325 
326 
327 
328 
329
A to Z: JavaDoc & Examples Daily Java News & Articles Open Source Projects Open Source Codes Free Computer Books Remove Frame
Popular Tags