Unexpected thread wakeup

Question

I was expecting the second thread in the following example to hang, since it waits on an object with no corresponding notify. Instead, it falls through to the println, presumably due to a spurious wakeup.

public class Spurious {
    public static void main(String[] args) {

        Thread t1 = new Thread() { 
            public void run() { 
                System.out.println("Hey!"); 
            }  
        };
        Thread t2 = new Thread() { 
            public void run() 
            {
                try {
                    synchronized (t1) {
                        t1.wait();
                    }
                } catch (InterruptedException e) {
                    return;
                }
                System.out.println("Done.");
            }
        };
        t1.start();
        t2.start();
    }
}

Output:

Hey!
Done.

On the other hand, if one removes the "Hey!" println from the first thread, the second thread will indeed hang. This happens on both MacOS and Linux.

Any idea why?

Just a guess, but maybe death of a thread causes a spurious wakeup of any waiters. Without the `println()` maybe t1 is already dead before t2 begins waiting, and has missed that spurious wakeup. — erickson, Mar 02 '16 at 19:07
Read the javadoc of Object.wait() and Thread.join(). You should not call wait on an object of type Thread. It notifies when it stops, to wake up other threads that joined it. — JB Nizet, Mar 02 '16 at 19:11
@JBNizet seems to be right. Although I am not able to find it in the Javadoc, if you used a lock like `final Object lock = new Object()` and `t2` waits on it (instead of waiting on `t1`), then it always hangs. — Kedar Mhaswade, Mar 02 '16 at 19:19

Nathan Hughes · Accepted Answer · 2019-09-26T12:43:14.510

This is not a spurious wakeup, a spurious wakeup is caused by a race condition in the JVM. This is a race condition in your code.

The println keeps thread1 alive just long enough that thread2 can start waiting before thread1 terminates.

Once thread1 terminates it sends a notification to everything waiting on its monitor. thread2 receives the notification and ceases waiting.

Removing the println reduces the time needed for thread1 to finish so that thread1 has already finished by the time thread2 can start waiting on it. thread1 is no longer alive and its notification has already occurred before thread2 started waiting, so thread2 waits forever.

That threads send a notification when they die is documented in the API for Thread#join:

This implementation uses a loop of this.wait calls conditioned on this.isAlive. As a thread terminates the this.notifyAll method is invoked. It is recommended that applications not use wait, notify, or notifyAll on Thread instances.

(For a thread to call notifyAll it has to hold the lock, if the other thread grabs the lock, it can keep the terminating thread alive and delay the notifyAll until the terminating thread can acquire the lock.)

The moral (well, one of the morals) is to always wait in a loop with a condition variable, see the Oracle tutorial. If you change Thread2 to look like this:

    Thread t2 = new Thread() { 
        public void run() 
        {
            try {
                synchronized (t1) {
                    while (t1.isAlive()) {
                        t1.wait();
                    }
                }
            } catch (InterruptedException e) {
                return;
            }
            System.out.println("Done.");
        }
    };

then thread2 should exit regardless of whether thread2 can start waiting before thread1 finishes.

Of course this is total toy example territory:

Don't extend Thread, use Runnable or Callable.
Don't lock on threads.
Don't start Threads, use Executors.
Prefer higher level concurrency constructs to wait/notify.

Thanks for the answer. You're saying termination of thread "t" implicitly signals all threads waiting on "t". Is this documented anywhere? I can't find it. — Marco, Mar 02 '16 at 19:50
Interesting: I didn't expect having to read Thread#join to learn something about Thread#wait! — Marco, Mar 02 '16 at 19:59

score 2 · Answer 2 · edited Mar 02 '16 at 19:22

2

You're waiting on a Thread object. That's bad practice, that is explicitly discouraged in the javadoc of Thread (Thread.join, precisely).

The reason is that when you call thread.join() to block until the thread stops running, you're actually waiting on the thread. And when the thread stops running, it notifies in order to unblock all the callers of join().

Since you waited on the thread, you're implicitly being notified when the thread stops running.

edited Mar 02 '16 at 19:22

Nathan Hughes

94,330
19
181
276

answered Mar 02 '16 at 19:18

JB Nizet

678,734
91
1,224
1,255

This is not the correct answer; the poster has a race condition. `Thread.Wait()` will block indefinitely if the thread has already stopped. It'll block and then release if the thread is running and finishes. – antiduh Mar 02 '16 at 19:38
Err yes, so what? The question was about the "spurious" wakeup. And my answer explains it. I don't see how the fact that there is a race condition makes the explanation incorrect. – JB Nizet Mar 02 '16 at 19:58
Because there was no spurious wakeup in the code; the poster was confused as to the cause of their bug. – antiduh Mar 02 '16 at 20:31

Unexpected thread wakeup

2 Answers2

Linked