...
To guarantee safety, programs must test the while loop condition after returning from the wait() method. Although wait() is intended to block indefinitely until a notification is received, it must still be encased within a loop to prevent the following vulnerabilities [Bloch 2001]:
- 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 third thread can change the state of the object, leaving it inconsistent. This is a TOCTOU race condition.
- Malicious notification �€” ��‚��€? A random or malicious notification can be received when the condition predicate is false. Such a notification would cancel the
wait(). - Misdelivered notification �€” ��‚��€? The order in which threads execute after receipt of a
notifyAll()signal is unspecified. Consequently, an unrelated thread could start executing and discover that its condition predicate is satisfied. Consequently, it could resume execution, although it was required to remain dormant. - Spurious wakeups �€” ��‚��€? Certain JVM implementations are vulnerable to spurious wakeups that result in waiting threads waking up even without a notification [API 2006].
...