[concurrency-interest] Re: spurious wakeups semantics (more history & refs)

Pete Soper Pete.Soper at Sun.COM
Fri Nov 4 11:35:39 EST 2005


Here are some details to go along with Josh's msg about this.

David J. Biesack wrote:
> Another question: Are spurious wakeups allowed in Java 1.4, or is it only in 1.5 that they are allowed? 

The 1.4.2 javadoc for java.lang.Object does not mention spurious
wakeups, nor does Chapter 17 of JLS 2.0.

 Or do 1.4 JVMs disallow them and incur the performance penalties
mentioned in this thread?
> 
> I assume they may occur in 1.4 (and earlier VMs) but just have not been documented.

 See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4974934 which
may have come

 from a FindBugs analysis of 1.4 source.
> 

The bug of interest is 4308396 "Java wait/notify should require
condition variable, allow spurious wakeups" filed against 1.4.0. Here is
the description:

"The current Java Language Specification definition of wait, notify,
   and notifyAll does not require that they be done within a "condition
   variable" paradigm.  The requested change would be to require that
   wait be called from within a loop that tests for a logical condition
   variable, and that notify and notifyAll change the value of that
   condition variable, and that when wait returns the value of the
condition
   variable must be checked to see that it has changed, otherwise the
   loop continues and the wait is reentered.  A corollary of the requested
   change is that waits may return due to spurious wakeups, meaning
operating
   system events unconnected to any action within the Java program."



And the eval:

"The spec should and will be clarified to indicate that spurious wakeups
can occur.  This is one of the many reasons that wait should *always* be
used inside a loop (See Item 50 in Bloch's "Effective Java.")

Note that this does not affect the JLS, which no longer contains the
specifications for the core libraries.  It will affect only the
documentation of the Object.wait method.

--- 2003-01-21


I applaud the proposed change to the specification, but HotSpot JVM
implementors should be aware that for compatibility reaons our
_implementation_  is not permitted to return spuriously from wait().

--- 2003-10-07"

This change was delivered into Java SE 5 ("Tiger") and went into JLS 3.0
as well as the lib javadoc despite the remark above.

The end result is typified by the Object.wait() doc shown here:

 http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#wait()

Bug 4777391 "unexpected behaviour of Object.wait method" came before the
spec update but shows an extreme case of not having a condition ("test
should be hung !!!" is printed due to a notify by the system).

public class hang extends Thread {
    public static void main(String argv[]) {
        Thread thread = new hang();

        System.out.println("prepare to hang !!");
        try {
            synchronized (thread) {
                thread.start();  /*1*/
    	        thread.wait();   /*2*/
            }

            System.out.println("test should be hung !!!");
        } catch (InterruptedException e) {
            System.out.println("InterruptedException" + e);
        }
    }
}


-Pete


More information about the Concurrency-interest mailing list