Page History

Threads that invoke Object.wait() expect to wake up and resume execution when their condition predicate becomes true. To be compliant with rule THI03-J. Always invoke wait() and await() methods inside a loop, waiting threads must test their condition predicates upon receiving notifications and must resume waiting if the predicates are false.

The notify() and notifyAll() methods of package java.lang.Object are used to wake up waiting thread(s). These methods must be invoked from a thread that holds the same object lock as the waiting thread(s); these methods throw an IllegalMonitorStateException when invoked from any other thread. The notifyAll() method wakes up all threads associated with waiting on an object lock and allows threads whose condition predicate is true to resume execution. Furthermore, if all the threads whose condition predicate evaluates to true previously held a specific lock before going into the wait state, only one of them will reacquire the lock upon being notified. Presumably, the other threads will resume waiting. The notify() method wakes up only one thread, and any with no guarantee regarding which specific thread is notified. The chosen thread is permitted to resume waiting if its condition predicate is unsatisfied; , and this often defeats the purpose of the notification.

...

These conditions are satisfied by threads that are identical and provide a stateless service or utility.

The java.util.concurrent.locks utilities (Condition interface) provide the Condition.signal() and Condition.signalAll() methods to awaken threads that are blocked on an a Condition.await() call. Condition objects are required when using java.util.concurrent.locks.Lock objects. A Lock object allows the use of Object.wait() and notify, Object.notify(), and Object.notifyAll() methods. However, code that synchronizes using , however this is prohibited by rule "LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects". However, code that synchronizes using a Lock object uses one or more Condition objects associated with the Lock object rather than using its own intrinsic lock. These objects interact directly with the locking policy enforced by the Lock object. Consequently, the Condition.await(), Condition.signal(), and Condition.signalAll() methods are used in place of the Object.wait(), Object.notify(), and Object.notifyAll() methods.

Use of the The signal() method is insecure when multiple threads await the same Condition object unless the following must not be used unless all of these conditions are met:

• The Condition object is identical for each waiting thread.
• All threads must perform the same set of operations after waking up. This means that any one thread can be selected to wake up and resume for a single invocation of signal().
• Only one thread is required to wake upon receiving the signal.

Insecure use of the signal() method is forbidden.

• signal.

or all of these Use of the signal() method is also permitted when both of the following conditions are met:

• Each thread uses a unique Condition object.
• Each Condition object is associated with a common Lock object.

The When used securely, the signal() method has better performance than signalAll() when used securely.

Noncompliant Code Example (notify())

...

...