A thread Threads that invokes invoke wait()
expects expect to wake up and resume execution when its their condition predicate becomes true. Waiting threads must test their condition predicates upon receiving notifications and resume waiting if the predicates are false, to 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 code a thread that holds the same object lock as the waiting thread(s). An IllegalMonitorStateException
is thrown if the current thread does not acquire this object's intrinsic lock before invoking these methods; these methods throw an IllegalMonitorStateException
when invoked from any other thread. The notifyAll()
method wakes up all threads associated with 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 makes no guarantees as to which , and any guarantee regarding which specific thread is notified. If the thread's condition predicate doesn't allow the thread to proceed, the chosen thread may resume waiting, defeating The chosen thread is permitted to resume waiting if its condition predicate is unsatisfied; this often defeats the purpose of the notification.
The Consequently, the invoking the notify()
method may only be invoked if is permitted only when all of the following conditions are met:
- The condition predicate is identical for each waiting threadAll waiting threads have identical condition predicates.
- All threads must perform the same set of operations after waking up. This means that That is, any one thread can be selected to wake up and resume for a single invocation of
notify()
. - Only one thread is required to wake upon the notification.
...
The java.util.concurrent
utilities (Condition
interface) provide the signal()
and signalAll()
methods to awaken threads that are blocked on an await()
call. Condition
objects are required when using Lock
objects. A Lock
object allows the use of wait()
and notify()
methods. However, code that synchronizes using a Lock
object does not use its own intrinsic lock. Instead, uses one or more Condition
objects are 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 instead in place of the Object.wait()
, Object.notify()
, and Object.notifyAll()
methods.
The use Use of the signal()
method is insecure when multiple threads await the same Condition
object unless the following 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.the signal.
Insecure use of the signal()
method is forbidden.
Use of the The signal()
method may is also be invoked permitted when both of the following conditions are met:
- Each thread uses a unique
Condition
object. - Each
Condition
object is associated with a commonLock
object.
The signal()
method , if used securely, has better performance than signalAll()
when used securely.
Noncompliant Code Example (notify()
)
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3250361f1f1deafd-8ed6337d-44684541-9f88ab23-e7c0fc9f010e648010a922fb"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="09293eb39fc899fd-dbde7bfb-4dd146c2-81fd9e2a-a7e726f2e22584bfca480fc9"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | [Chapter 17, Threads and Locks | http://java.sun.com/docs/books/jls/third_edition/html/memory.html] | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1cfd4a00072ecf68-77b4248e-45b640b2-a28ea893-76bced7560d060117f6e8b82"><ac:plain-text-body><![CDATA[ | [[Goetz 2006 | AA. Bibliography#Goetz 06]] | Section 14.2.4, Notification | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="afc94b76272898dd-5b482787-40e94d0a-aef9a2aa-60c7f555d51b25d037b8864d"><ac:plain-text-body><![CDATA[ | [[Bloch 2001 | AA. Bibliography#Bloch 01]] | Item 50: Never invoke wait outside a loop | ]]></ac:plain-text-body></ac:structured-macro> |
...