1 |
tim |
1.1 |
package java.util.concurrent; |
2 |
|
|
|
3 |
|
|
import java.util.Date; |
4 |
|
|
|
5 |
|
|
/** |
6 |
|
|
* <tt>Conditions</tt> abstract out the <tt>Object</tt> monitor |
7 |
|
|
* methods ({@link Object#wait() wait}, {@link Object#notify notify} and |
8 |
|
|
* {@link Object#notifyAll notifyAll}) into distinct objects that can be bound |
9 |
|
|
* to other objects to give the effect of having multiple wait-sets per |
10 |
|
|
* object monitor. They also generalise the monitor methods to allow them to |
11 |
|
|
* be used with arbitrary {@link Lock} implementations when needed. |
12 |
|
|
* |
13 |
|
|
* <p>Conditions (also known as condition queues or condition variables) |
14 |
|
|
* provide |
15 |
|
|
* a means for one thread to suspend execution (to "wait") until |
16 |
|
|
* notified by another thread that some state-condition the first thread is |
17 |
|
|
* waiting for may now be true. Because access to this shared state information |
18 |
|
|
* occurs in different threads, it must be protected and invariably |
19 |
|
|
* a lock, of some form, is always associated with the condition. The key |
20 |
|
|
* property that waiting for a condition provides is that it |
21 |
|
|
* <em>atomically</em> releases the associated lock and suspends the current |
22 |
|
|
* thread. |
23 |
|
|
* |
24 |
|
|
* <p>A <tt>Condition</tt> instance is intrinsically bound to a lock: either |
25 |
|
|
* the in-built monitor lock of an object, or a {@link Lock} instance. |
26 |
|
|
* To obtain a <tt>Condition</tt> instance for a particular object's monitor |
27 |
|
|
* lock |
28 |
|
|
* use the {@link Locks#newConditionFor(Object)} method. |
29 |
|
|
* To obtain a <tt>Condition</tt> instance for a particular {@link Lock} |
30 |
|
|
* instance use its {@link Lock#newCondition} method. |
31 |
|
|
* |
32 |
|
|
* <p>As an example, suppose we have a bounded buffer which supports methods |
33 |
|
|
* to <tt>put</tt> and <tt>take</tt> items in/from the buffer. If a |
34 |
|
|
* <tt>take</tt> is attempted on an empty buffer then the thread will block |
35 |
|
|
* until an item becomes available; if a <tt>put</tt> is attempted on a |
36 |
|
|
* full buffer, then the thread will block until a space becomes available. |
37 |
|
|
* We would like to keep waiting <tt>put</tt> threads and <tt>take</tt> |
38 |
|
|
* threads in separate wait-sets so that we can use the optimisation of |
39 |
|
|
* only notifying a single thread at a time when items, or spaces, become |
40 |
|
|
* available in the buffer. This can be achieved using either two |
41 |
|
|
* {@link Condition} instances, or one {@link Condition} instance and the |
42 |
|
|
* actual |
43 |
|
|
* monitor wait-set. For clarity we'll use two {@link Condition} instances. |
44 |
|
|
* <pre><code> |
45 |
|
|
* class BoundedBuffer { |
46 |
|
|
* <b>final Condition notFull = Locks.newConditionFor(this); |
47 |
|
|
* final Condition notEmpty = Locks.newConditionFor(this); </b> |
48 |
|
|
* |
49 |
|
|
* Object[] items = new Object[100]; |
50 |
|
|
* int putptr, takeptr, count; |
51 |
|
|
* |
52 |
|
|
* public <b>synchronized</b> void put(Object x) |
53 |
|
|
* throws InterruptedException { |
54 |
|
|
* while (count == items.length) |
55 |
|
|
* <b>notFull.await();</b> |
56 |
|
|
* items[putptr] = x; |
57 |
|
|
* if (++putptr == items.length) putptr = 0; |
58 |
|
|
* ++count; |
59 |
|
|
* <b>notEmpty.signal();</b> |
60 |
|
|
* } |
61 |
|
|
* |
62 |
|
|
* public <b>synchronized</b> Object take() throws InterruptedException { |
63 |
|
|
* while (count == 0) |
64 |
|
|
* <b>notEmpty.await();</b> |
65 |
|
|
* Object x = items[takeptr]; |
66 |
|
|
* if (++takeptr == items.length) takeptr = 0; |
67 |
|
|
* --count; |
68 |
|
|
* <b>notFull.signal();</b> |
69 |
|
|
* return x; |
70 |
|
|
* } |
71 |
|
|
* } |
72 |
|
|
* </code></pre> |
73 |
|
|
* |
74 |
|
|
* <p>If we were to use a standalone {@link Lock} object, such as a |
75 |
|
|
* {@link ReentrantLock} then we would write the example as so: |
76 |
|
|
* <pre><code> |
77 |
|
|
* class BoundedBuffer { |
78 |
|
|
* <b>Lock lock = new ReentrantLock();</b> |
79 |
|
|
* final Condition notFull = <b>lock.newCondition(); </b> |
80 |
|
|
* final Condition notEmpty = <b>lock.newCondition(); </b> |
81 |
|
|
* |
82 |
|
|
* Object[] items = new Object[100]; |
83 |
|
|
* int putptr, takeptr, count; |
84 |
|
|
* |
85 |
|
|
* public void put(Object x) throws InterruptedException { |
86 |
|
|
* <b>lock.lock(); |
87 |
|
|
* try {</b> |
88 |
|
|
* while (count == items.length) |
89 |
|
|
* <b>notFull.await();</b> |
90 |
|
|
* items[putptr] = x; |
91 |
|
|
* if (++putptr == items.length) putptr = 0; |
92 |
|
|
* ++count; |
93 |
|
|
* <b>notEmpty.signal();</b> |
94 |
|
|
* <b>} finally { |
95 |
|
|
* lock.unlock(); |
96 |
|
|
* }</b> |
97 |
|
|
* } |
98 |
|
|
* |
99 |
|
|
* public Object take() throws InterruptedException { |
100 |
|
|
* <b>lock.lock(); |
101 |
|
|
* try {</b> |
102 |
|
|
* while (count == 0) |
103 |
|
|
* <b>notEmpty.await();</b> |
104 |
|
|
* Object x = items[takeptr]; |
105 |
|
|
* if (++takeptr == items.length) takeptr = 0; |
106 |
|
|
* --count; |
107 |
|
|
* <b>notFull.signal();</b> |
108 |
|
|
* return x; |
109 |
|
|
* <b>} finally { |
110 |
|
|
* lock.unlock(); |
111 |
|
|
* }</b> |
112 |
|
|
* } |
113 |
|
|
* } |
114 |
|
|
* </code></pre> |
115 |
|
|
* |
116 |
|
|
* <p>A <tt>Condition</tt> implementation can provide behavior and semantics |
117 |
|
|
* that is |
118 |
|
|
* different from that of the <tt>Object</tt> monitor methods, such as |
119 |
|
|
* guaranteed ordering for notifications, or not requiring a lock to be held |
120 |
|
|
* when performing notifications. |
121 |
|
|
* If an implementation provides such specialised semantics then the |
122 |
|
|
* implementation must document those semantics. |
123 |
|
|
* |
124 |
|
|
* <p>Note that <tt>Condition</tt> instances are just normal objects and can |
125 |
|
|
* themselves be used as the target in a <tt>synchronized</tt> statement, |
126 |
|
|
* and can have their own monitor {@link Object#wait wait} and |
127 |
|
|
* {@link Object#notify notification} methods invoked. |
128 |
|
|
* Acquiring the monitor lock of a <tt>Condition</tt> instance, or using its |
129 |
|
|
* monitor methods has no specified relationship with acquiring the |
130 |
|
|
* {@link Lock} associated with that <tt>Condition</tt> or the use of it's |
131 |
|
|
* {@link #await waiting} and {@link #signal signalling} methods. |
132 |
|
|
* It is recommended that to avoid confusion you never use <tt>Condition</tt> |
133 |
|
|
* instances in this way, except perhaps within their own implementation. |
134 |
|
|
* |
135 |
|
|
* <p>Except where noted, passing a <tt>null</tt> value for any parameter |
136 |
|
|
* will result in a {@link NullPointerException} being thrown. |
137 |
|
|
* |
138 |
|
|
* <h3>Implementation Considerations</h3> |
139 |
|
|
* |
140 |
|
|
* <p>When waiting upon a <tt>Condition</tt> instance a "<em>spurious |
141 |
|
|
* wakeup</em>" is permitted to occur, in |
142 |
|
|
* general, as a concession to the underlying platform semantics. |
143 |
|
|
* This has little practical impact on most application programs as a |
144 |
|
|
* <tt>Condition</tt> should always be waited upon in a loop, testing |
145 |
|
|
* the state predicate that is being waited for. An implementation is |
146 |
|
|
* free to remove the possibility of spurious wakeups but it is |
147 |
|
|
* recommended that applications programmers always assume that they can |
148 |
|
|
* occur and so always wait in a loop. |
149 |
|
|
* |
150 |
|
|
* <p>It is recognised that the three forms of condition waiting |
151 |
|
|
* (interruptible, non-interruptible, and timed) may differ in their ease of |
152 |
|
|
* implementation on some platforms and in their performance characteristics. |
153 |
|
|
* In particular, it may be difficult to provide these features and maintain |
154 |
|
|
* specific semantics such as ordering guarantees. |
155 |
|
|
* Further, the ability to interrupt the actual suspension of the thread may |
156 |
|
|
* not always be feasible to implement on all platforms. |
157 |
|
|
* <p>Consequently, an implementation is not required to define exactly the |
158 |
|
|
* same guarantees or semantics for all three forms of waiting, nor is it |
159 |
|
|
* required to support interruption of the actual suspension of the thread. |
160 |
|
|
* <p>An implementation is required to |
161 |
|
|
* clearly document the semantics and guarantees provided by each of the |
162 |
|
|
* waiting methods, and when an implementation does support interruption of |
163 |
|
|
* thread suspension then it must obey the interruption semantics as defined |
164 |
|
|
* in this interface. |
165 |
|
|
* |
166 |
|
|
* |
167 |
|
|
* @since 1.5 |
168 |
|
|
* @spec JSR-166 |
169 |
|
|
* @revised $Date: 2003/01/30 22:13:23 $ |
170 |
|
|
* @editor $Author: dholmes $ |
171 |
|
|
*/ |
172 |
|
|
public interface Condition { |
173 |
|
|
|
174 |
|
|
/** |
175 |
|
|
* Causes the current thread to wait until it is signalled or |
176 |
|
|
* {@link Thread#interrupt interrupted}. |
177 |
|
|
* |
178 |
|
|
* <p>The lock associated with this <tt>Condition</tt> is atomically |
179 |
|
|
* released and the current thread becomes disabled for thread scheduling |
180 |
|
|
* purposes and lies dormant until <em>one</em> of four things happens: |
181 |
|
|
* <ul> |
182 |
|
|
* <li>Some other thread invokes the {@link #signal} method for this |
183 |
|
|
* <tt>Condition</tt> and the current thread happens to be chosen as the |
184 |
|
|
* thread to be awakened; or |
185 |
|
|
* <li>Some other thread invokes the {@link #signalAll} method for this |
186 |
|
|
* <tt>Condition</tt>; or |
187 |
|
|
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
188 |
|
|
* thread, and interruption of thread suspension is supported; or |
189 |
|
|
* <li>A "<em>spurious wakeup</em>" occurs |
190 |
|
|
* </ul> |
191 |
|
|
* |
192 |
|
|
* <p>In all cases, before this method can return the current thread must |
193 |
|
|
* re-acquire the lock associated with this condition. When the |
194 |
|
|
* thread returns it is <em>guaranteed</em> to hold this lock. |
195 |
|
|
* |
196 |
|
|
* <p>If the current thread: |
197 |
|
|
* <ul> |
198 |
|
|
* <li>has its interrupted status set on entry to this method; or |
199 |
|
|
* <li>is {@link Thread#interrupt interrupted} while waiting |
200 |
|
|
* and interruption of thread suspension is supported, |
201 |
|
|
* </ul> |
202 |
|
|
* then {@link InterruptedException} is thrown and the current thread's |
203 |
|
|
* interrupted status is cleared. It is not specified, in the first |
204 |
|
|
* case, whether or not the test for interruption occurs before the lock |
205 |
|
|
* is released. |
206 |
|
|
* |
207 |
|
|
* <p>The circumstances under which the wait completes are mutually |
208 |
|
|
* exclusive. For example, if the thread is signalled then it will |
209 |
|
|
* never return by throwing {@link InterruptedException}; conversely |
210 |
|
|
* a thread that is interrupted and throws {@link InterruptedException} |
211 |
|
|
* will never consume a {@link #signal}. |
212 |
|
|
* |
213 |
|
|
* <p><b>Implementation Considerations</b> |
214 |
|
|
* <p>The current thread is assumed to hold the lock associated with this |
215 |
|
|
* <tt>Condition</tt> when this method is called. |
216 |
|
|
* It is up to the implementation to determine if this is |
217 |
|
|
* the case and if not, how to respond. Typically, an exception will be |
218 |
|
|
* thrown (such as {@link IllegalMonitorStateException}) and the |
219 |
|
|
* implementation must document that fact. |
220 |
|
|
* |
221 |
|
|
* @throws InterruptedException if the current thread is interrupted (and |
222 |
|
|
* interruption of thread suspension is supported). |
223 |
|
|
*/ |
224 |
|
|
void await() throws InterruptedException; |
225 |
|
|
|
226 |
|
|
/** |
227 |
|
|
* Causes the current thread to wait until it is signalled. |
228 |
|
|
* |
229 |
|
|
* <p>The lock associated with this condition is atomically |
230 |
|
|
* released and the current thread becomes disabled for thread scheduling |
231 |
|
|
* purposes and lies dormant until <em>one</em> of three things happens: |
232 |
|
|
* <ul> |
233 |
|
|
* <li>Some other thread invokes the {@link #signal} method for this |
234 |
|
|
* <tt>Condition</tt> and the current thread happens to be chosen as the |
235 |
|
|
* thread to be awakened; or |
236 |
|
|
* <li>Some other thread invokes the {@link #signalAll} method for this |
237 |
|
|
* <tt>Condition</tt>; or |
238 |
|
|
* <li>A "<em>spurious wakeup</em>" occurs |
239 |
|
|
* </ul> |
240 |
|
|
* |
241 |
|
|
* <p>In all cases, before this method can return the current thread must |
242 |
|
|
* re-acquire the lock associated with this condition. When the |
243 |
|
|
* thread returns it is <em>guaranteed</em> to hold this lock. |
244 |
|
|
* |
245 |
|
|
* <p>If the current thread's interrupt status is set when it enters |
246 |
|
|
* this method, or it is {@link Thread#interrupt interrupted} |
247 |
|
|
* while waiting, it will continue to wait until signalled. When it finally |
248 |
|
|
* returns from this method it's <em>interrupted status</em> will still |
249 |
|
|
* be set. |
250 |
|
|
* |
251 |
|
|
* <p><b>Implementation Considerations</b> |
252 |
|
|
* <p>The current thread is assumed to hold the lock associated with this |
253 |
|
|
* <tt>Condition</tt> when this method is called. |
254 |
|
|
* It is up to the implementation to determine if this is |
255 |
|
|
* the case and if not, how to respond. Typically, an exception will be |
256 |
|
|
* thrown (such as {@link IllegalMonitorStateException}) and the |
257 |
|
|
* implementation must document that fact. |
258 |
|
|
* |
259 |
|
|
*/ |
260 |
|
|
void awaitUninterruptibly(); |
261 |
|
|
|
262 |
|
|
/** |
263 |
|
|
* Causes the current thread to wait until it is signalled or |
264 |
|
|
* {@link Thread#interrupt interrupted}, |
265 |
|
|
* or the specified waiting time elapses. |
266 |
|
|
* |
267 |
|
|
* <p>The lock associated with this condition is atomically |
268 |
|
|
* released and the current thread becomes disabled for thread scheduling |
269 |
|
|
* purposes and lies dormant until <em>one</em> of five things happens: |
270 |
|
|
* <ul> |
271 |
|
|
* <li>Some other thread invokes the {@link #signal} method for this |
272 |
|
|
* <tt>Condition</tt> and the current thread happens to be chosen as the |
273 |
|
|
* thread to be awakened; or |
274 |
|
|
* <li>Some other thread invokes the {@link #signalAll} method for this |
275 |
|
|
* <tt>Condition</tt>; or |
276 |
|
|
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
277 |
|
|
* thread, and interruption of thread suspension is supported; or |
278 |
|
|
* <li>The specified waiting time elapses; or |
279 |
|
|
* <li>A "<em>spurious wakeup</em>" occurs. |
280 |
|
|
* </ul> |
281 |
|
|
* |
282 |
|
|
* <p>In all cases, before this method can return the current thread must |
283 |
|
|
* re-acquire the lock associated with this condition. When the |
284 |
|
|
* thread returns it is <em>guaranteed</em> to hold this lock. |
285 |
|
|
* |
286 |
|
|
* <p>If the current thread: |
287 |
|
|
* <ul> |
288 |
|
|
* <li>has its interrupted status set on entry to this method; or |
289 |
|
|
* <li>is {@link Thread#interrupt interrupted} while waiting |
290 |
|
|
* and interruption of thread suspension is supported, |
291 |
|
|
* </ul> |
292 |
|
|
* then {@link InterruptedException} is thrown and the current thread's |
293 |
|
|
* interrupted status is cleared. It is not specified, in the first |
294 |
|
|
* case, whether or not the test for interruption occurs before the lock |
295 |
|
|
* is released. |
296 |
|
|
* |
297 |
|
|
* <p>If the specified time has elapsed then a value less than or |
298 |
|
|
* equal to zero is returned. Otherwise this method returns an estimate |
299 |
|
|
* of the number of nanoseconds |
300 |
|
|
* remaining to wait given the supplied <tt>nanosTimeout</tt> |
301 |
|
|
* value. |
302 |
|
|
* This value can be used to determine whether and how |
303 |
|
|
* long to re-wait in cases where the wait returns but the |
304 |
|
|
* condition still does not hold. Typical uses of this method take |
305 |
|
|
* the following form: |
306 |
|
|
* |
307 |
|
|
* <pre> |
308 |
|
|
* synchronized boolean aMethod(long timeout, TimeUnit unit) { |
309 |
|
|
* long nanosTimeout = unit.toNanos(timeout); |
310 |
|
|
* while (!conditionBeingWaitedFor) { |
311 |
|
|
* if (nanosTimeout > 0) |
312 |
|
|
* nanosTimeout = theCondition.awaitNanos(nanosTimeout); |
313 |
|
|
* else |
314 |
|
|
* return false; |
315 |
|
|
* } |
316 |
|
|
* // ... |
317 |
|
|
* return true; |
318 |
|
|
* } |
319 |
|
|
* </pre> |
320 |
|
|
* |
321 |
|
|
* <p>The circumstances under which the wait completes are mutually |
322 |
|
|
* exclusive. For example, if the thread is signalled then it will |
323 |
|
|
* never return by throwing {@link InterruptedException}; conversely |
324 |
|
|
* a thread that is interrupted and throws {@link InterruptedException} |
325 |
|
|
* will never consume a {@link #signal}. |
326 |
|
|
* |
327 |
|
|
* <p> Design note: This method requires a nanosecond argument so |
328 |
|
|
* as to avoid truncation errors in reporting remaining times. |
329 |
|
|
* Such precision loss would make it difficult for programmers to |
330 |
|
|
* ensure that total waiting times are not systematically shorter |
331 |
|
|
* than specified when re-waits occur. |
332 |
|
|
* |
333 |
|
|
* <p><b>Implementation Considerations</b> |
334 |
|
|
* <p>The current thread is assumed to hold the lock associated with this |
335 |
|
|
* <tt>Condition</tt> when this method is called. |
336 |
|
|
* It is up to the implementation to determine if this is |
337 |
|
|
* the case and if not, how to respond. Typically, an exception will be |
338 |
|
|
* thrown (such as {@link IllegalMonitorStateException}) and the |
339 |
|
|
* implementation must document that fact. |
340 |
|
|
* |
341 |
|
|
* @param nanosTimeout the maximum time to wait, in nanoseconds |
342 |
|
|
* @return an estimate, that |
343 |
|
|
* is strictly less than the <tt>nanosTimeout</tt> argument, |
344 |
|
|
* of the time still remaining when this method returned. |
345 |
|
|
* If the specified time has elapsed |
346 |
|
|
* then a value less than or equal to zero is returned. |
347 |
|
|
* |
348 |
|
|
* @throws InterruptedException if the current thread is interrupted (and |
349 |
|
|
* interruption of thread suspension is supported). |
350 |
|
|
*/ |
351 |
|
|
long awaitNanos(long nanosTimeout) throws InterruptedException; |
352 |
|
|
|
353 |
|
|
|
354 |
|
|
|
355 |
|
|
/** |
356 |
|
|
* Causes the current thread to wait until it is signalled or interrupted, |
357 |
|
|
* or the specified absolute deadline passes. |
358 |
|
|
* |
359 |
|
|
* <p>The lock associated with this condition is atomically |
360 |
|
|
* released and the current thread becomes disabled for thread scheduling |
361 |
|
|
* purposes and lies dormant until <em>one</em> of five things happens: |
362 |
|
|
* <ul> |
363 |
|
|
* <li>Some other thread invokes the {@link #signal} method for this |
364 |
|
|
* <tt>Condition</tt> and the current thread happens to be chosen as the |
365 |
|
|
* thread to be awakened; or |
366 |
|
|
* <li>Some other thread invokes the {@link #signalAll} method for this |
367 |
|
|
* <tt>Condition</tt>; or |
368 |
|
|
* <li> Some other thread {@link Thread#interrupt interrupts} the current |
369 |
|
|
* thread, and interruption of thread suspension is supported; or |
370 |
|
|
* <li>The specified absolute deadline passes; or |
371 |
|
|
* <li>A "<em>spurious wakeup</em>" occurs. |
372 |
|
|
* </ul> |
373 |
|
|
* |
374 |
|
|
* <p>In all cases, before this method can return the current thread must |
375 |
|
|
* re-acquire the lock associated with this condition. When the |
376 |
|
|
* thread returns it is <em>guaranteed</em> to hold this lock. |
377 |
|
|
* |
378 |
|
|
* |
379 |
|
|
* <p>If the current thread: |
380 |
|
|
* <ul> |
381 |
|
|
* <li>has its interrupted status set on entry to this method; or |
382 |
|
|
* <li>is {@link Thread#interrupt interrupted} while waiting |
383 |
|
|
* and interruption of thread suspension is supported, |
384 |
|
|
* </ul> |
385 |
|
|
* then {@link InterruptedException} is thrown and the current thread's |
386 |
|
|
* interrupted status is cleared. It is not specified, in the first |
387 |
|
|
* case, whether or not the test for interruption occurs before the lock |
388 |
|
|
* is released. |
389 |
|
|
* |
390 |
|
|
* <p>If the specified deadline has passed then the value <tt>false</tt> |
391 |
|
|
* is returned. This return value |
392 |
|
|
* This value can be used to determine whether |
393 |
|
|
* to re-wait in cases where the wait returns but the |
394 |
|
|
* condition still does not hold. Typical uses of this method take |
395 |
|
|
* the following form: |
396 |
|
|
* <pre> |
397 |
|
|
* synchronized boolean aMethod(Date deadline) { |
398 |
|
|
* boolean stillWaiting = true; |
399 |
|
|
* while (!conditionBeingWaitedFor) { |
400 |
|
|
* if (stillwaiting) |
401 |
|
|
* stillWaiting = theCondition.awaitUntil(deadline); |
402 |
|
|
* else |
403 |
|
|
* return false; |
404 |
|
|
* } |
405 |
|
|
* // ... |
406 |
|
|
* return true; |
407 |
|
|
* } |
408 |
|
|
* |
409 |
|
|
* </pre> |
410 |
|
|
* <p>The circumstances under which the wait completes are mutually |
411 |
|
|
* exclusive. For example, if the thread is signalled then it will |
412 |
|
|
* never return by throwing {@link InterruptedException}; conversely |
413 |
|
|
* a thread that is interrupted and throws {@link InterruptedException} |
414 |
|
|
* will never consume a {@link #signal}. |
415 |
|
|
* |
416 |
|
|
* <p><b>Implementation Considerations</b> |
417 |
|
|
* <p>The current thread is assumed to hold the lock associated with this |
418 |
|
|
* <tt>Condition</tt> when this method is called. |
419 |
|
|
* It is up to the implementation to determine if this is |
420 |
|
|
* the case and if not, how to respond. Typically, an exception will be |
421 |
|
|
* thrown (such as {@link IllegalMonitorStateException}) and the |
422 |
|
|
* implementation must document that fact. |
423 |
|
|
* |
424 |
|
|
* |
425 |
|
|
* @param deadline the absolute time to wait until |
426 |
|
|
* @return <tt>false</tt> if the deadline passed, and |
427 |
|
|
* <tt>true</tt> otherwise. |
428 |
|
|
* |
429 |
|
|
* @throws InterruptedException if the current thread is interrupted (and |
430 |
|
|
* interruption of thread suspension is supported). |
431 |
|
|
*/ |
432 |
|
|
boolean awaitUntil(Date deadline) throws InterruptedException; |
433 |
|
|
|
434 |
|
|
/** |
435 |
|
|
* Wakes up one waiting thread. |
436 |
|
|
* |
437 |
|
|
* <p>If any threads are waiting on this condition then one |
438 |
|
|
* is selected for waking up. That thread must then re-acquire the |
439 |
|
|
* lock before returning from <tt>await</tt>. |
440 |
|
|
*/ |
441 |
|
|
void signal(); |
442 |
|
|
|
443 |
|
|
/** |
444 |
|
|
* Wakes up all waiting threads. |
445 |
|
|
* |
446 |
|
|
* <p>If any threads are waiting on this condition then they are |
447 |
|
|
* all woken up. Each thread must re-acquire the lock before it can |
448 |
|
|
* return from <tt>await</tt>. |
449 |
|
|
*/ |
450 |
|
|
void signalAll(); |
451 |
|
|
|
452 |
|
|
} |
453 |
|
|
|
454 |
|
|
|
455 |
|
|
|
456 |
|
|
|