The Object wait() documentation says "Causes current thread to wait
until another thread invokes the notify() method or the notifyAll()
method for this object."

The structure of the program appears to exclude a spurious notify, it is
not using notifyAll, and there are no Java interrupts. Under those
conditions, wouldn't a spurious return from wait represent a bug in the
wait implementation, a failure to conform to its API documentation?

Patricia

On 27 Nov, 19:45, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:

I think I have found the reason why some people say there can be
spurious wakeups. I think they are right and I was wrong. The key to
me understanding it is due to this web page, from Sun:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html. Here is
says:

---
As in the one argument version, interrupts and spurious wakeups are
possible, and this method should always be used in a loop:

    synchronized (obj) {
        while (<condition does not hold>)
            obj.wait(timeout, nanos);
        ... // Perform action appropriate to condition
    }
---
This text appears when discussing the two argument version and the
zero argument version, i.e it applies for all flavours of wait. So it
is nothing to do with whether or not timeouts are used. I am aware
that the underlying operating system primitives that do timed waits
can be awoken prematurely, as described by Butenhof. It is quite
conceivable that this behaviour is passed on to java. But I am calling
wait with no arguments and did not think the same concerns applied.
The sun java page shows I was wrong. I had better go and fix my code!

-Andrew Marlow

According to Brian Goetz, Java Concurrency In Practice, "Additionally,
wait is even allowed to return 'spuriously' -not in response to any
thread calling notify."

And he has a list of rules for using condition waits

1 Always have a condition predicate - some test of object state that
must hold before proceeding
2 Always test the condition predicate before calling wait() and again
after returning from wait
3 Always call wait in a loop (my note - I guess that makes 1&2 simpler)
4 Ensure that the state variable making up the condition predicate are
guarded by the lock associated with the condition queue
5 Hold the lock associated with the condition queue when calling wait,
notify or notifyAll
6 Do not release the lock after checking the condition predicate but
before acting on it

synchronized (lock) {
    while (!conditionPredicate)
        lock.wait();
}

And the releasing code

synchronized (lock) {
    conditionPredicate = true;
    lock.notify();
}

As to where the in the JLS spurious wakeups are allowed, I don't know.

    The situation you describe is unusually simple.  So simple
that there seems no technical reason to use threads at all (you
mention that the multi-thread framework was imposed by external
forces).  In your simple situation, the "wrong" way will work
just fine -- but will your situation remain this simple forever?

    Useful programs have a way of evolving, of extending, of
finding themselves employed in new circumstances.  Ponder a
few of the kinds of things that might happen:

    - Somebody decides that the single "supplier" thread makes
      poor use of his multi-core CPU, and decides to divide the
      work across eight suppliers in hopes of better throughput.
      Your condition for proceeding changes from "The supplier
      is no longer active" to "The count of active suppliers
      has gone to zero."  As each supplier finishes it will call
      notify() just in case it was the last, and all but the
      last awakening will be a false alarm.

    - An additional "consumer" is added, maybe to do auditing
      or logging or something.  This consumer is also interested
      in the list of items, but wants to be awakened every time
      an item is added.  Your original "accumulator" and the new
      consumer both wait() on the list, and the supplier now
      calls notifyAll() for every new item and for the "poison
      pill" at the end, and all but one of these is a false alarm
      as far as your accumulator thread is concerned.

    - The same external forces that dictated threading to begin
      with may dictate weird changes that will require some
      threads to call notify() before it's really time for your
      accumulator to proceed.  Your accumulator must be prepared
      to be awakened prematurely and to go back to sleep.

    Here's the nub: The caller of notify() doesn't know what the
caller of wait() is waiting for.  That's the waiter's business,
after all, expressed in the waiter's code.  All the notifier
needs to know is that the change it has just made to some object
*may* be *part* of something another thread waits for, so it
calls notify() to give the waiter a chance to make its own decision.
Some of those awakenings may be "genuine" in the sense that notify()
was truly called, but "spurious" in the sense that the condition
being waited for does not yet hold.  It's a kind of encapsulation,
if you like, that limits the amount of shared knowledge that must
be spread around to the many parts of your program.

    Summary:  Always use

    synchronized(thing) {
       while (! readyToGo())
           thing.wait();
       doLockedThings(thing);
    }
    doOtherThings(thing);

... because it will always be safe, no matter what happens.  In
absurdly simple situations you could change `if' to `while', but
why tempt Fate?  In any case it is *never* correct to write

    synchronized(thing) {
       thing.wait();  // unguarded wait is R-O-N-G!
       doLockedThings(thing);
    }
    doOtherThings(thing);

... and the Google phrase for this error is "lost wakeup."