Page History

The Object.wait() method is used to temporarily cede cedes possession of a lock so that another thread that is requesting the lock can proceed. It Object.wait() must always be used inside called from a synchronized block or method. To make resume the waiting thread resume, the requesting thread must notify() it. Furthermore, the wait() method should be invoked in a loop that checks if a condition predicate holds. Note that a condition predicate is not the same as negation of the condition expression in the loop. For example, the condition predicate for removing an element from a vector is !isEmpty() whereas the condition expression for the while loop condition is isEmpty(). The correct way to invoke wait() when the vector is empty is shown below.

...

The notification mechanism notifies the waiting thread and lets it check its condition predicate. The invocation of notify() or notifyAll() in another thread cannot precisely determine which waiting thread will be is resumed. A condition predicate statement is provided so that only the correct thread will resume upon receiving the notification. A condition predicate also helps when a thread is required to block until a condition becomes true , for instance, when it should not proceed without reading some such as reading data from an input stream before proceeding.

When using the wait/notify mechanism, two properties come into the picture:

Safety

...

 and liveness are both concerns when using the wait/notify mechanism.  Safety requires that all objects maintain consistent states in a multi-threaded environment

...

 \[[Lea 00|AA. Java References#Lea 00]\]

...

. Liveness requires that every operation or method invocation execute to completion without interruption.

To guarantee liveness, the while loop condition should must be tested before invoking the wait() method. This is because in case another thread has already satisfied the condition predicate might have already been made true by some other thread with a good chance that the same thread also sent out a notify signaland sent a notification. Invoking the wait() method after the notify signal has been sent is futile and results in an indefinite blocking.

To guarantee _safety_, the {{while}} loop condition must be tested even after invoking {{wait()}}. While {{wait()}} is meant to block indefinitely until a notification is received, it shouldmust still be encased within a loop to prevent the following vulnerabilities \[[Bloch 01|AA. Java References#Bloch 01]\], to prevent the following vulnerabilities:

• 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 resuming execution. This thread can change the state of the object, leaving it inconsistent. This is a time of check, time of use (TOCTOU) condition.
• Malicious notification: There is no guarantee that a random notification will not be received when the condition predicate is false. This means that the invocation of wait() may be nullified by the notification.
• Mis-delivered Misdelivered notification: Sometimes on receipt of a notifyAll() signal, an unrelated thread can start executing and it is possible for its condition predicate to be true. Consequently, it may resume execution whilst although it was required to remain dormant.

• Wiki Markup
  Spurious wake wakeupsups: Certain JVM implementations are vulnerable to _spurious wake wakeupsups_ that result in waiting threads waking up even without a notification \[[API 06|AA. Java References#API 06]\].

Because of For these reasons, it is indispensable necessary to check the condition predicate after wait() is invoked. A while loop is the best choice for checking the condition predicate before and after invoking wait().

...

When waiting upon a Condition, a "spurious wakeup" is permitted to occur, in general, as a concession to the underlying platform semantics. This has little practical impact on most application programs as a Condition should always be waited upon in a loop, testing the state predicate that is being waited for. An implementation is free to remove the possibility of spurious wakeups but it is recommended that applications programmers always assume that they can occur and so always wait in a loop.

Newer New code should use the java.util.concurrent concurrency utilities as opposed to instead of the wait/notify mechanism. However, however, legacy code may require depend upon the wait/notify mechanism.

...

This noncompliant code example invokes the wait() method inside a traditional if block and fails to check the post condition after the notification (is received. If the notification is accidental or malicious) is received. This means that , the thread can wake up when it is not supposed to do soprematurely.

synchronized (object) {
  if (<condition does not hold>) {
    object.wait();
  }
  // Proceed when condition holds
}

Compliant Solution

This compliant solution encloses calls the wait() method in from within a while loop and as a result checks to check the condition during both pre before and post after wait() invocation times is called.

synchronized (object) {
  while (<condition does not hold>) {
    object.wait(); 
  }
  // Proceed when condition holds
}

Similarly, invocations of the await() method of the java.util.concurrent.locks.Condition interface should always must be enclosed in a loop.

Risk Assessment

To guarantee liveness and safety, the wait() and await() methods should must always be invoked inside a while loop.

...