CON16-J. Do not expect sleep(), yield() and getState() methods to have any synchronization semantics

According to the Java Language Specification [[JLS 05]], section 17.9 "Sleep and Yield":

It is important to note that neither Thread.sleep nor Thread.yield have any synchronization semantics. In particular, the compiler does not have to flush writes cached in registers out to shared memory before a call to Thread.sleep or Thread.yield, nor does the compiler have to reload values cached in registers after a call to Thread.sleep or Thread.yield.

The assumption that thread suspension and yielding flush the cached registers and reload the values when execution resumes, is misleading and paves the way for potential coding errors.

The Thread.getState() method returns the current state of a thread. Using this method for synchronization control such as checking whether a thread is blocked on a wait is inappropriate because a blocked thread is not always required to enter the WAITING or TIMED_WAITING state in cases where the JVM chooses to implement the blocking using spin-waiting [[Goetz 06]].

Noncompliant Code Example

This noncompliant code example declares a non-volatile Boolean flag.

private Boolean done;
while (!this.done) {
  Thread.sleep(1000);
}

"The compiler is free to read the field this.done just once, and reuse the cached value in each execution of the loop. This would mean that the loop would never terminate, even if another thread changed the value of this.done." [[JLS 05]]. This occurs because Thread.sleep() does not establish a [happens-before] relation.

Compliant Solution

This compliant solution declares the flag volatile to ensure that updates to it are made visible across multiple threads.

private volatile Boolean done;
while (!this.done) {
  Thread.sleep(1000);
}

The volatile flag establishes a happens-before relation between this thread and any other thread that sets done.

Risk Assessment

Relying on class Thread's sleep(), yield() and getState() methods for synchronization control can cause unexpected behavior.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[JLS 05]] section 17.9 "Sleep and Yield"

CON15-J. Ensure actively held locks are released on exceptional conditions      11. Concurrency (CON)      CON17-J. Avoid using ThreadGroup APIs