1 |
/* |
2 |
* Written by Doug Lea with assistance from members of JCP JSR-166 |
3 |
* Expert Group and released to the public domain. Use, modify, and |
4 |
* redistribute this code in any way without acknowledgement. |
5 |
*/ |
6 |
|
7 |
package java.util.concurrent; |
8 |
|
9 |
/** |
10 |
* <tt>Lock</tt> implementations provide more flexible locking operations than |
11 |
* can be obtained using <tt>synchronized</tt> methods and statements. |
12 |
* |
13 |
* <p>A lock is a tool for controlling access to a shared |
14 |
* resource by multiple threads. Commonly, a lock provides exclusive access |
15 |
* to a shared resource: only one thread at a time can acquire the |
16 |
* lock and all access to the shared resource requires that the lock be |
17 |
* acquired first. However, some locks may allow concurrent access to a shared |
18 |
* resource, such as the read lock of a {@link ReadWriteLock}. |
19 |
* |
20 |
* <p>The use of <tt>synchronized</tt> methods or statements provides |
21 |
* access to the implicit monitor lock associated with every object, but |
22 |
* forces all lock acquisition and release to occur in a block-structured way: |
23 |
* when multiple locks are acquired they must be released in the opposite |
24 |
* order, and all locks must be released in the same lexical scope in which |
25 |
* they were acquired. |
26 |
* |
27 |
* <p>While the scoping mechanism for <tt>synchronized</tt> methods and |
28 |
* statements makes it much easier to program with monitor locks, |
29 |
* and helps avoid many common programming errors involving locks, there are |
30 |
* rare occasions where you need to work with locks in a more flexible way. For |
31 |
* example, some advanced algorithms for traversing concurrently accessed data |
32 |
* structures require the use of what is called "hand-over-hand" or |
33 |
* "chain locking": you acquire the lock of node A, then node B, |
34 |
* then release A and acquire C, then release B and acquire D and so on. |
35 |
* Implementations of the <tt>Lock</tt> interface facilitate the use of such |
36 |
* advanced algorithms by allowing a lock to be acquired and released in |
37 |
* different scopes, and allowing multiple locks to be acquired and released |
38 |
* in any order. |
39 |
* |
40 |
* <p>With this increased flexibilty comes |
41 |
* additional responsibility as the absence of block-structured locking |
42 |
* removes the automatic release of locks that occurs with |
43 |
* <tt>synchronized</tt> methods and statements. For the simplest usage |
44 |
* the following idiom should be used: |
45 |
* <pre><tt> Lock l = ...; |
46 |
* l.lock(); |
47 |
* try { |
48 |
* // access the resource protected by this lock |
49 |
* } finally { |
50 |
* l.unlock(); |
51 |
* } |
52 |
* </tt></pre> |
53 |
* |
54 |
* <p><tt>Lock</tt> implementations provide additional functionality over the |
55 |
* use |
56 |
* of <tt>synchronized</tt> methods and statements by providing a non-blocking |
57 |
* attempt to acquire a lock ({@link #tryLock()}), an attempt to acquire the |
58 |
* lock that can be interrupted ({@link #lockInterruptibly}, and an attempt |
59 |
* to acquire the lock that can timeout ({@link #tryLock(long, TimeUnit)}). |
60 |
* This additional functionality is also extended to built-in monitor |
61 |
* locks through the methods of the {@link Locks} utility class. |
62 |
* |
63 |
* <p>A <tt>Lock</tt> class can also provide behavior and semantics that is |
64 |
* quite different from that of the implicit monitor lock, such as guaranteed |
65 |
* ordering, |
66 |
* non-reentrant usage, or deadlock detection. If an implementation provides |
67 |
* such specialised semantics then the implementation must document those |
68 |
* semantics. |
69 |
* |
70 |
* <p>Note that <tt>Lock</tt> instances are just normal objects and can |
71 |
* themselves be used as the target in a <tt>synchronized</tt> statement. |
72 |
* Acquiring the |
73 |
* monitor lock of a <tt>Lock</tt> instance has no specified relationship |
74 |
* with invoking any of the {@link #lock} methods of that instance. |
75 |
* It is recommended that to avoid confusion you never use <tt>Lock</tt> |
76 |
* instances in this way, except within their own implementation. |
77 |
* |
78 |
* <p>Except where noted, passing a <tt>null</tt> value for any parameter |
79 |
* will result in a {@link NullPointerException} being thrown. |
80 |
* |
81 |
* <h3>Memory Synchronization</h3> |
82 |
* <p>All <tt>Lock</tt> implementations <em>must</em> enforce the same |
83 |
* memory synchronization semantics as provided by the built-in monitor lock: |
84 |
* <ul> |
85 |
* <li>A successful lock operation acts like a successful |
86 |
* <tt>monitorEnter</tt> action |
87 |
* <li>A successful <tt>unlock</tt> operation acts like a successful |
88 |
* <tt>monitorExit</tt> action |
89 |
* </ul> |
90 |
* Note that unsuccessful locking and unlocking operations, and reentrant |
91 |
* locking/unlocking operations, do not require any memory synchronization |
92 |
* effects. |
93 |
* |
94 |
* <h3>Implementation Considerations</h3> |
95 |
* <p>It is recognised that the three forms of lock acquisition (interruptible, |
96 |
* non-interruptible, and timed) may differ in their ease of implementation |
97 |
* on some platforms and in their performance characteristics. |
98 |
* In particular, it may be difficult to provide these features and maintain |
99 |
* specific semantics such as ordering guarantees. |
100 |
* Further, the ability to interrupt the acquisition of a lock may not always |
101 |
* be feasible to implement on all platforms. |
102 |
* <p>Consequently, an implementation is not required to define exactly the |
103 |
* same |
104 |
* guarantees or semantics for all three forms of lock acquistion, nor is it |
105 |
* required to support interruption of the actual lock acquisition. |
106 |
* An implementation is required to clearly |
107 |
* document the semantics and guarantees provided by each of the locking |
108 |
* methods. It must also obey the interruption semantics as defined in this |
109 |
* interface, to the extent that interruption of lock acquisition is |
110 |
* supported: which is either totally, or only on method entry. |
111 |
* <p>As interruption generally implies cancellation, and checks for |
112 |
* interruption are often infrequent, an implementation can favor responding |
113 |
* to an interrupt over normal method return. This is true even if it can be |
114 |
* shown that the interrupt occurred after another action may have unblocked |
115 |
* the thread. An implementation should document this behaviour. |
116 |
* |
117 |
* |
118 |
* @see ReentrantLock |
119 |
* @see Condition |
120 |
* @see ReadWriteLock |
121 |
* @see Locks |
122 |
* |
123 |
* @since 1.5 |
124 |
* @spec JSR-166 |
125 |
* @revised $Date: 2003/06/24 14:34:48 $ |
126 |
* @editor $Author: dl $ |
127 |
* @author Doug Lea |
128 |
* |
129 |
**/ |
130 |
public interface Lock { |
131 |
|
132 |
/** |
133 |
* Acquires the lock. |
134 |
* <p>Acquires the lock if it is available and returns immediately. |
135 |
* <p>If the lock is not available then |
136 |
* the current thread becomes disabled for thread scheduling |
137 |
* purposes and lies dormant until the lock has been acquired. |
138 |
* <p><b>Implementation Considerations</b> |
139 |
* <p>A <tt>Lock</tt> implementation may be able to detect |
140 |
* erroneous use of the lock, such as an invocation that would cause |
141 |
* deadlock, and may throw an (unchecked) exception in such circumstances. |
142 |
* The circumstances and the exception type must be documented by that |
143 |
* <tt>Lock</tt> implementation. |
144 |
* |
145 |
**/ |
146 |
void lock(); |
147 |
|
148 |
/** |
149 |
* Acquires the lock unless the current thread is |
150 |
* {@link Thread#interrupt interrupted}. |
151 |
* <p>Acquires the lock if it is available and returns immediately. |
152 |
* <p>If the lock is not available then |
153 |
* the current thread thread becomes disabled for thread scheduling |
154 |
* purposes and lies dormant until one of two things happens: |
155 |
* <ul> |
156 |
* <li> The lock is acquired by the current thread; or |
157 |
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
158 |
* thread, and interruption of lock acquisition is supported. |
159 |
* </ul> |
160 |
* <p>If the current thread: |
161 |
* <ul> |
162 |
* <li>has its interrupted status set on entry to this method; or |
163 |
* <li>is {@link Thread#interrupt interrupted} while acquiring |
164 |
* the lock, and interruption of lock acquisition is supported, |
165 |
* </ul> |
166 |
* then {@link InterruptedException} is thrown and the current thread's |
167 |
* interrupted status is cleared. |
168 |
* |
169 |
* <p><b>Implementation Considerations</b> |
170 |
* <p>The ability to interrupt a lock acquisition in some implementations |
171 |
* may not be possible, and if possible could reasonably be foreseen to |
172 |
* be an expensive operation. |
173 |
* The programmer should be aware that this may be the case. An |
174 |
* implementation should document when this is the case. |
175 |
* <p>An implementation can favor responding to an interrupt over |
176 |
* normal method return. |
177 |
* <p>A <tt>Lock</tt> implementation may be able to detect |
178 |
* erroneous use of the lock, such as an invocation that would cause |
179 |
* deadlock, and may throw an (unchecked) exception in such circumstances. |
180 |
* The circumstances and the exception type must be documented by that |
181 |
* <tt>Lock</tt> implementation. |
182 |
* |
183 |
* @throws InterruptedException if the current thread is interrupted |
184 |
* while acquiring the lock (and interruption of lock acquisition is |
185 |
* supported). |
186 |
* |
187 |
* @see Thread#interrupt |
188 |
* |
189 |
**/ |
190 |
void lockInterruptibly() throws InterruptedException; |
191 |
|
192 |
|
193 |
/** |
194 |
* Acquires the lock only if it is free at the time of invocation. |
195 |
* <p>Acquires the lock if it is available and returns immediately |
196 |
* with the value <tt>true</tt>. |
197 |
* <p>If the lock is not available then this method will return |
198 |
* immediately with the value <tt>false</tt>. |
199 |
* <p>A typical usage idiom for this method would be: |
200 |
* <pre> |
201 |
* Lock lock = ...; |
202 |
* if (lock.tryLock()) { |
203 |
* try { |
204 |
* // manipulate protected state |
205 |
* } finally { |
206 |
* lock.unlock(); |
207 |
* } |
208 |
* } else { |
209 |
* // perform alternative actions |
210 |
* } |
211 |
* </pre> |
212 |
* This usage ensures that the lock is unlocked if it was acquired, and |
213 |
* doesn't try to unlock if the lock was not acquired. |
214 |
* |
215 |
* @return <tt>true</tt> if the lock was acquired and <tt>false</tt> |
216 |
* otherwise. |
217 |
**/ |
218 |
boolean tryLock(); |
219 |
|
220 |
/** |
221 |
* Acquires the lock if it is free within the given waiting time and the |
222 |
* current thread has not been {@link Thread#interrupt interrupted}. |
223 |
* <p>Acquires the lock if it is available and returns immediately |
224 |
* with the value <tt>true</tt>. |
225 |
* <p>If the lock is not available then |
226 |
* the current thread becomes disabled for thread scheduling |
227 |
* purposes and lies dormant until one of three things happens: |
228 |
* <ul> |
229 |
* <li> The lock is acquired by the current thread; or |
230 |
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
231 |
* thread, and interruption of lock acquisition is supported; or |
232 |
* <li> The specified waiting time elapses |
233 |
* </ul> |
234 |
* <p>If the lock is acquired then the value <tt>true</tt> is returned. |
235 |
* <p>If the current thread: |
236 |
* <ul> |
237 |
* <li>has its interrupted status set on entry to this method; or |
238 |
* <li>is {@link Thread#interrupt interrupted} while acquiring |
239 |
* the lock, and interruption of lock acquisition is supported, |
240 |
* </ul> |
241 |
* then {@link InterruptedException} is thrown and the current thread's |
242 |
* interrupted status is cleared. |
243 |
* <p>If the specified waiting time elapses then the value <tt>false</tt> |
244 |
* is returned. |
245 |
* The given waiting time is a best-effort lower bound. If the time is |
246 |
* less than or equal to zero, the method will not wait at all. |
247 |
* |
248 |
* <p><b>Implementation Considerations</b> |
249 |
* <p>The ability to interrupt a lock acquisition in some implementations |
250 |
* may not be possible, and if possible could reasonably be foreseen to |
251 |
* be an expensive operation. |
252 |
* The programmer should be aware that this may be the case. An |
253 |
* implementation should document when this is the case. |
254 |
* <p>An implementation can favor responding to an interrupt over normal |
255 |
* method return, or reporting a timeout. |
256 |
* <p>A <tt>Lock</tt> implementation may be able to detect |
257 |
* erroneous use of the lock, such as an invocation that would cause |
258 |
* deadlock, and may throw an (unchecked) exception in such circumstances. |
259 |
* The circumstances and the exception type must be documented by that |
260 |
* <tt>Lock</tt> implementation. |
261 |
* |
262 |
* @param time the maximum time to wait for the lock |
263 |
* @param unit the time unit of the <tt>time</tt> argument. |
264 |
* @return <tt>true</tt> if the lock was acquired and <tt>false</tt> |
265 |
* if the waiting time elapsed before the lock was acquired. |
266 |
* |
267 |
* @throws InterruptedException if the current thread is interrupted |
268 |
* while acquiring the lock (and interruption of lock acquisition is |
269 |
* supported). |
270 |
* |
271 |
* @see Thread#interrupt |
272 |
* |
273 |
**/ |
274 |
boolean tryLock(long time, TimeUnit unit) throws InterruptedException; |
275 |
|
276 |
/** |
277 |
* Releases the lock. |
278 |
* <p><b>Implementation Considerations</b> |
279 |
* <p>A <tt>Lock</tt> implementation will usually impose |
280 |
* restrictions on which thread can release a lock (typically only the |
281 |
* holder of the lock can release it) and may throw |
282 |
* an (unchecked) exception if the restriction is violated. |
283 |
* Any restrictions and the exception |
284 |
* type must be documented by that <tt>Lock</tt> implementation. |
285 |
**/ |
286 |
void unlock(); |
287 |
|
288 |
/** |
289 |
* Returns a {@link Condition} instance that is bound to this <tt>Lock</tt> |
290 |
* instance. |
291 |
* <p>Conditions are primarily used with the built-in locking provided by |
292 |
* <tt>synchronized</tt> methods and statements |
293 |
* (see {@link Locks#newConditionFor}), but in some rare circumstances it |
294 |
* can be useful to wait for a condition when working with a data |
295 |
* structure that is accessed using a stand-alone <tt>Lock</tt> instance |
296 |
* (see {@link ReentrantLock}). |
297 |
* <p>Before waiting on the condition the lock must be held by the |
298 |
* current thread. |
299 |
* A call to {@link Condition#await()} will atomically release the lock |
300 |
* before waiting and re-acquire the lock before the wait returns. |
301 |
* <p><b>Implementation Considerations</b> |
302 |
* <p>The exact operation of the {@link Condition} instance depends on the |
303 |
* <tt>Lock</tt> implementation and must be documented by that |
304 |
* implementation. |
305 |
* |
306 |
* @return A {@link Condition} instance for this <tt>Lock</tt> instance. |
307 |
* @throws UnsupportedOperationException if this <tt>Lock</tt> |
308 |
* implementation does not support conditions. |
309 |
**/ |
310 |
Condition newCondition(); |
311 |
|
312 |
} |
313 |
|
314 |
|
315 |
|
316 |
|
317 |
|
318 |
|
319 |
|
320 |
|
321 |
|
322 |
|
323 |
|
324 |
|