Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Partial update; stopped for the day just before the first NCCE.

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 common Lock 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]]

java.util.concurrent.locks.Condition interface

]]></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>

...