CODEWITHSUNDEEP
javamultithreading
Nebeski
Nebeski

Reputation: 610

Using this.wait() inside run() in a synchronized block

I have this code:

public class Nit extends Thread {
    public void run() {
        try {
            synchronized(this) {
                this.wait();
            }
            System.out.println("AAA");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        Nit n = new Nit();
        n.start();
        synchronized(n) {
            n.notify();
        }
    }
}

When I run it from cmd it never exits like it is an infinite loop. I don't understand why. Only thing i can think of is that Nit n is still waiting but I don't get why?

Upvotes: 2

Views: 658

Answers (2)

Nathan Hughes
Nathan Hughes

Reputation: 96385

The notify method tells the scheduler to pick a thread to notify, choosing from only those threads that are currently waiting on the same lock that notify was called on.

In this case the n thread doesn't start waiting until after the notification has already happened, so nothing ever wakes the thread up from waiting. You may have assumed that waiting threads will see notifications made before they started waiting, or that the JVM would have to give the n thread CPU time before the main thread proceeds past the call to start, but those assumptions aren't valid.

Introduce a condition flag as an instance member of Nit:

public class Nit extends Thread {
    boolean notified = false;

and change Nit's run method to check it:

synchronized (this) {
    while (!notified) {
        wait();
    }
}

Then add a line to the main method so that the main thread can set the flag:

synchronized (n) {
    n.notified = true;
    n.notify();
}

This way the notify can still happen before n starts waiting, but in that case n will check the flag, see it's true already, and skip waiting.

See Oracle's guarded blocks tutorial:

Note: Always invoke wait inside a loop that tests for the condition being waited for.

Also the API documentation (see Thread.join) discourages the practice of locking on thread objects.

Upvotes: 1

GhostCat
GhostCat

Reputation: 140427

You are observing a race condition. You notify before the wait happens. Therefore the wait sits there and waits forever.

If you would invoke this code often enough, you might see it passing sometimes - when the new thread advanced faster then the main thread. One way to make the example work: try adding a call to Thread.sleep(1000) or so before calling notify(). Alternatively, even a println() call on the main thread (before the notify() might change timing enough).

Beyond that: such subtleties are the main reason why you actually avoid using the "low level" primitives such as as wait/notify. Instead, you use the powerful abstractions (like queues) that standard APIs have to offer.

Upvotes: 4

Related Questions