The wait()
method is employed used to temporarily cede possession of a lock so that another requesting thread can proceed. It must always be used inside a synchronized
block. To resume activity, the other requesting thread must notify the waiting thread. Moreover, the wait()
method should be invoked in a loop that checks if a condition predicate holds.
A condition statement is used so that the correct thread is notified as The invocation of notify()
or notifyAll()
in another thread cannot pin point which waiting thread must be resumed. A condition predicate statement is used so that the correct thread is notified. Another use is that sometimes a thread is required to block until a condition becomes true, for instance, when it cannot proceed without obtaining some data from a stream.
Code Block |
---|
synchronized (object) { while (<condition does not hold>) { object.wait(); } //proceed Proceed when condition holds } |
Two properties come into the picture:
...
To guarantee liveness, the while
loop condition should be tested before proceeding to invoke wait
invoking the wait()
method. This is because the condition might already be true which indicates that a notify has signal may have already been sent from the other thread. Invoking the wait()
method after the notify signal has already been sent invites an infinite blocking infinitely blocked state.
Wiki Markup |
---|
To guarantee _safety_, the {{while}} loop condition must be tested even after the call to {{wait()}}. While {{wait()}} is meant to block indefinitely till a notification is received, this practice is touted because: \[[Bloch 01|AA. Java References#Bloch 01]\] |
- Thread in the middle: A third thread can acquire the lock on the shared object during the interval between a notification being sent and the receiving thread actually resuming execution. This thread can change the state of the object leaving it inconsistent. This is akin to the "time of callcheck, time of use" (TOCTOU) condition.
- Malicious notifications: There is no guarantee that a notification will not be sent when the condition does not hold. This means that the invocation of
wait()
is nullified by the notification. - Sometimes on receipt of a
notifyAll()
signal, an unrelated thread can start executing and it is possible for its condition to be true. - Certain JVM implementations are vulnerable to spurious wakeups that result in waiting threads waking up even without a notification.
Because of these reasons, it is indispensable to check the condition using a loop, after wait()
is called.
Noncompliant Code Example
This noncompliant code example invokes the wait()
method inside a traditional if
block and fails to check the post condition after the notification (accidental or malicious) is received. This means that the thread can waken wake up when it is not supposed to.
...
Code Block | ||
---|---|---|
| ||
//condition Condition predicate is guarded by a lock on the shared object/variable synchronized (object) { while (<condition does not hold>) { object.wait(); } //proceed Proceed when condition holds } |
Likewise, if the await()
method of the {java.util.concurrent.locks.Condition}} interface is implemented, it should be enclosed in a loop.
...
To guarantee liveness and safety, the wait()
and await()
method methods should always be called inside a while
loop.
...