Page History

...

• Liveness: Every operation or method invocation executes to completion without interruptions, even if it goes against safety.

• Wiki Markup
  Safety: Its main goal is to ensure that all objects maintain consistent states in a multi-threaded environment. \[[

  Doug Lea

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

To guarantee liveness, the while loop condition should be tested before proceeding to invoke wait. This is because the condition might be true which indicates that a notify has already been sent from the other thread. Invoking wait after the notify has already been sent invites an infinite blocking state.

To guarantee _safety_, the while loop condition should be tested even after the call to {{wait}}. While wait is meant to block indefinitely till a notification is received, this practice is touted because:

 \[[Bloch 01|AA. Java References#Bloch 01]\] 

• 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 actually resuming execution. This thread can change the state of the object leaving it inconsistent. This is akin to the "time of call, time of use" (TOCTOU) condition.
• Malicious notifications: There is no guarantee that a notification will not be sent when the condition does not hold. This means that the invocation of wait will be nullified by the notification.
• Sometimes on receipt of a notifyAll signal, an unrelated thread can start executing and it is possible for its condition to be true.
• Certain JVM implementations are vulnerable to spurious wakeups, that result in waiting threads waking up even without a notification.

Due to these reasons, checking the condition after wait is called is indispensable.

Noncompliant Code Example

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

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

Compliant Solution

The compliant solution encloses the wait method in a while loop and as a result checks the condition during both pre and post wait invocation times.

//condition predicate is guarded by a lock on the shared object/variable
synchronized (object) {
  while (<condition does not hold>) {
    object.wait(); 
  }

  //proceed when condition holds
}

Risk Assessment

TODOTo guarantee liveness and safety, the {[wait()}} method should always be called inside a while loop.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

...

Wiki Markup
\[[Bloch 01|AA. Java References#Bloch 01]\] Item 50: Never invoke wait outside a loop \[[Lea 00|AA. Java References#Lea 00]\]

EJPLG Item 50, Never invoke wait outside a loop
Doug Lea

3.2.2 Monitor Mechanics, 1.3.2

Liveness
Concurrency

Liveness \[[Goetz 06|AA. Java References#Goetz 06]\] Section 14.2

.

, Using Condition

Queues
Java Documentation, Object

Queues \[[API 06|AA. Java References#API 06]\] [Object|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html

^{Image Removed}

]