1 |
dl |
1.2 |
/* |
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 |
tim |
1.1 |
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 additionally 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 |
|
|
* |
112 |
|
|
* |
113 |
|
|
* @see ReentrantLock |
114 |
|
|
* @see Condition |
115 |
|
|
* @see ReadWriteLock |
116 |
|
|
* @see Locks |
117 |
|
|
* |
118 |
|
|
* @since 1.5 |
119 |
|
|
* @spec JSR-166 |
120 |
dl |
1.2 |
* @revised $Date: 2002/12/16 01:12:33 $ |
121 |
tim |
1.1 |
* @editor $Author: dholmes $ |
122 |
|
|
* |
123 |
dl |
1.2 |
**/ |
124 |
tim |
1.1 |
public interface Lock { |
125 |
|
|
|
126 |
|
|
/** |
127 |
|
|
* Acquires the lock. |
128 |
|
|
* <p>Acquires the lock if it is available and returns immediately. |
129 |
|
|
* <p>If the lock is not available then |
130 |
|
|
* the current thread becomes disabled for thread scheduling |
131 |
|
|
* purposes and lies dormant until the lock has been acquired. |
132 |
|
|
* <p><b>Implementation Considerations</b> |
133 |
|
|
* <p>A <tt>Lock</tt> implementation may be able to detect |
134 |
|
|
* erroneous use of the lock, such as an invocation that would cause |
135 |
|
|
* deadlock, and may throw an (unchecked) exception in such circumstances. |
136 |
|
|
* The circumstances and the exception type must be documented by that |
137 |
|
|
* <tt>Lock</tt> implementation. |
138 |
|
|
* |
139 |
dl |
1.2 |
**/ |
140 |
|
|
public void lock(); |
141 |
tim |
1.1 |
|
142 |
|
|
/** |
143 |
|
|
* Acquires the lock unless the current thread is |
144 |
|
|
* {@link Thread#interrupt interrupted}. |
145 |
|
|
* <p>Acquires the lock if it is available and returns immediately. |
146 |
|
|
* <p>If the lock is not available then |
147 |
dl |
1.2 |
* the current thread thread becomes disabled for thread scheduling |
148 |
tim |
1.1 |
* purposes and lies dormant until one of two things happens: |
149 |
|
|
* <ul> |
150 |
|
|
* <li> The lock is acquired by the current thread; or |
151 |
|
|
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
152 |
|
|
* thread, and interruption of lock acquisition is supported. |
153 |
|
|
* </ul> |
154 |
|
|
* <p>If the current thread: |
155 |
|
|
* <ul> |
156 |
|
|
* <li>has its interrupted status set on entry to this method; or |
157 |
|
|
* <li>is {@link Thread#interrupt interrupted} while waiting to acquire |
158 |
|
|
* the lock, and interruption of lock acquisition is supported, |
159 |
|
|
* </ul> |
160 |
|
|
* then {@link InterruptedException} is thrown and the current thread's |
161 |
|
|
* interrupted status is cleared. |
162 |
|
|
* |
163 |
|
|
* <p><b>Implementation Considerations</b> |
164 |
|
|
* <p>The ability to interrupt a lock acquisition in some implementations |
165 |
|
|
* may not be possible, and if possible could reasonably be foreseen to |
166 |
|
|
* be an expensive operation. |
167 |
|
|
* The programmer should be aware that this may be the case. An |
168 |
|
|
* implementation should document when this is the case. |
169 |
|
|
* |
170 |
|
|
* <p>A <tt>Lock</tt> implementation may be able to detect |
171 |
|
|
* erroneous use of the lock, such as an invocation that would cause |
172 |
|
|
* deadlock, and may throw an (unchecked) exception in such circumstances. |
173 |
|
|
* The circumstances and the exception type must be documented by that |
174 |
|
|
* <tt>Lock</tt> implementation. |
175 |
|
|
* |
176 |
|
|
* @throws InterruptedException if the current thread is interrupted |
177 |
|
|
* (and interruption of lock acquisition is supported). |
178 |
|
|
* |
179 |
|
|
* @see Thread#interrupt |
180 |
|
|
* |
181 |
dl |
1.2 |
**/ |
182 |
|
|
public void lockInterruptibly() throws InterruptedException; |
183 |
tim |
1.1 |
|
184 |
|
|
|
185 |
|
|
/** |
186 |
|
|
* Acquires the lock only if it is free at the time of invocation. |
187 |
|
|
* <p>Acquires the lock if it is available and returns immediately |
188 |
|
|
* with the value <tt>true</tt>. |
189 |
|
|
* <p>If the lock is not available then this method will return |
190 |
|
|
* immediately with the value <tt>false</tt>. |
191 |
|
|
* <p>A typical usage idiom for this method would be: |
192 |
|
|
* <pre> |
193 |
|
|
* Lock lock = ...; |
194 |
|
|
* if (lock.tryLock()) { |
195 |
|
|
* try { |
196 |
|
|
* // manipulate protected state |
197 |
|
|
* } finally { |
198 |
|
|
* lock.unlock(); |
199 |
|
|
* } |
200 |
|
|
* } else { |
201 |
|
|
* // perform alternative actions |
202 |
|
|
* } |
203 |
|
|
* </pre> |
204 |
|
|
* This usage ensures that the lock is unlocked if it was acquired, and |
205 |
|
|
* doesn't try to unlock if the lock was not acquired. |
206 |
|
|
* |
207 |
|
|
* @return <tt>true</tt> if the lock was acquired and <tt>false</tt> |
208 |
|
|
* otherwise. |
209 |
dl |
1.2 |
**/ |
210 |
|
|
public boolean tryLock(); |
211 |
tim |
1.1 |
|
212 |
|
|
/** |
213 |
|
|
* Acquires the lock if it is free within the given waiting time and the |
214 |
|
|
* current thread has not been {@link Thread#interrupt interrupted}. |
215 |
|
|
* <p>Acquires the lock if it is available and returns immediately |
216 |
|
|
* with the value <tt>true</tt>. |
217 |
|
|
* <p>If the lock is not available then |
218 |
|
|
* the current thread becomes disabled for thread scheduling |
219 |
|
|
* purposes and lies dormant until one of three things happens: |
220 |
|
|
* <ul> |
221 |
|
|
* <li> The lock is acquired by the current thread; or |
222 |
|
|
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
223 |
|
|
* thread, and interruption of lock acquisition is supported; or |
224 |
|
|
* <li> The specified waiting time elapses |
225 |
|
|
* </ul> |
226 |
|
|
* <p>If the lock is acquired then the value <tt>true</tt> is returned. |
227 |
|
|
* <p>If the current thread: |
228 |
|
|
* <ul> |
229 |
|
|
* <li>has its interrupted status set on entry to this method; or |
230 |
|
|
* <li>is {@link Thread#interrupt interrupted} while waiting to acquire |
231 |
|
|
* the lock, and interruption of lock acquisition is supported, |
232 |
|
|
* </ul> |
233 |
|
|
* then {@link InterruptedException} is thrown and the current thread's |
234 |
|
|
* interrupted status is cleared. |
235 |
|
|
* <p>If the specified waiting time elapses then the value <tt>false</tt> |
236 |
|
|
* is returned. |
237 |
|
|
* The given waiting time is a best-effort lower bound. If the time is |
238 |
|
|
* less than or equal to zero, the method will not wait at all. |
239 |
|
|
* |
240 |
|
|
* <p><b>Implementation Considerations</b> |
241 |
|
|
* <p>The ability to interrupt a lock acquisition in some implementations |
242 |
|
|
* may not be possible, and if possible could reasonably be foreseen to |
243 |
|
|
* be an expensive operation. |
244 |
|
|
* The programmer should be aware that this may be the case. An |
245 |
|
|
* implementation should document when this is the case. |
246 |
|
|
* |
247 |
|
|
* <p>A <tt>Lock</tt> implementation may be able to detect |
248 |
|
|
* erroneous use of the lock, such as an invocation that would cause |
249 |
|
|
* deadlock, and may throw an (unchecked) exception in such circumstances. |
250 |
|
|
* The circumstances and the exception type must be documented by that |
251 |
|
|
* <tt>Lock</tt> implementation. |
252 |
|
|
* |
253 |
dl |
1.2 |
* @param time the maximum time to wait for the lock |
254 |
|
|
* @param unit the time unit of the <tt>time</tt> argument. |
255 |
tim |
1.1 |
* @return <tt>true</tt> if the lock was acquired and <tt>false</tt> |
256 |
|
|
* if the waiting time elapsed before the lock was acquired. |
257 |
|
|
* |
258 |
|
|
* @throws InterruptedException if the current thread is interrupted |
259 |
|
|
* while trying to acquire the lock (and interruption of lock |
260 |
|
|
* acquisition is supported). |
261 |
|
|
* |
262 |
|
|
* @see Thread#interrupt |
263 |
|
|
* |
264 |
dl |
1.2 |
**/ |
265 |
|
|
public boolean tryLock(long time, TimeUnit unit) throws InterruptedException; |
266 |
tim |
1.1 |
|
267 |
|
|
/** |
268 |
|
|
* Releases the lock. |
269 |
|
|
* <p><b>Implementation Considerations</b> |
270 |
|
|
* <p>A <tt>Lock</tt> implementation will usually impose |
271 |
|
|
* restrictions on which thread can release a lock (typically only the |
272 |
|
|
* holder of the lock can release it) and may throw |
273 |
|
|
* an (unchecked) exception if the restriction is violated. |
274 |
|
|
* Any restrictions and the exception |
275 |
|
|
* type must be documented by that <tt>Lock</tt> implementation. |
276 |
dl |
1.2 |
**/ |
277 |
|
|
public void unlock(); |
278 |
tim |
1.1 |
|
279 |
|
|
/** |
280 |
|
|
* Returns a {@link Condition} instance that is bound to this <tt>Lock</tt> |
281 |
|
|
* instance. |
282 |
|
|
* <p>Conditions are primarily used with the built-in locking provided by |
283 |
|
|
* <tt>synchronized</tt> methods and statements |
284 |
|
|
* (see {@link Locks#newConditionFor}), but in some rare circumstances it |
285 |
|
|
* can be useful to wait for a condition when working with a data |
286 |
|
|
* structure that is accessed using a stand-alone <tt>Lock</tt> instance |
287 |
|
|
* (see {@link ReentrantLock}). |
288 |
|
|
* <p>Before waiting on the condition the lock must be held by the |
289 |
|
|
* current thread. |
290 |
|
|
* A call to {@link Condition#await()} will atomically release the lock |
291 |
|
|
* before waiting and re-acquire the lock before the wait returns. |
292 |
|
|
* <p><b>Implementation Considerations</b> |
293 |
|
|
* <p>The exact operation of the {@link Condition} instance depends on the |
294 |
|
|
* <tt>Lock</tt> implementation and must be documented by that |
295 |
|
|
* implementation. |
296 |
|
|
* |
297 |
|
|
* @return A {@link Condition} instance for this <tt>Lock</tt> instance. |
298 |
|
|
* @throws UnsupportedOperationException if this <tt>Lock</tt> |
299 |
|
|
* implementation does not support conditions. |
300 |
dl |
1.2 |
**/ |
301 |
|
|
public Condition newCondition(); |
302 |
tim |
1.1 |
|
303 |
|
|
} |
304 |
|
|
|
305 |
|
|
|
306 |
|
|
|
307 |
|
|
|
308 |
|
|
|
309 |
|
|
|
310 |
|
|
|
311 |
|
|
|
312 |
|
|
|
313 |
|
|
|
314 |
|
|
|
315 |
|
|
|