Misunderstanding with the wait() method.

[Vadim Vararu]

package md.vararu.bean;

class Job extends Thread {
	private Integer number = 0;

	public void run() {
		for (int i = 1; i < 1000000; i++) {
			number++;
		}
	}

	public Integer getNumber() {
		return number;
	}
}

public class My {
	public static void main(String[] args) throws InterruptedException {
		Job thread = new Job();
		thread.start();
		synchronized (thread) {
			thread.wait();
		}
		System.out.println(thread.getNumber());
	}
}

Could you please explain, how it comes that i get printed the actual thread's value in the end, if, normally, the current thread should wait the invocation thread.notify() or thread.notifyAll() and it is not in the code? Thank you!

[John Stark]

Hm, for wait() it says 'Causes the current thread to wait until ...'. I guess it is the main thread which is waiting in your code. With the wait() in your code the printout is 999999, so the main thread waits until the Thread 'thread' has finished. If you remove the wait() then the printout is something like '143' on my computer, so execution of the main thread immediately continues after doing thread.start(). Not sure why there is no notify() necessary.

John

[Vadim Vararu]

John Stark wrote:Hm, for wait() it says 'Causes the current thread to wait until ...'. I guess it is the main thread which is waiting in your code. With the wait() in your code the printout is 999999, so the main thread waits until the Thread 'thread' has finished. If you remove the wait() then the printout is something like '143' on my computer, so execution of the main thread immediately continues after doing thread.start(). Not sure why there is no notify() necessary.

John

That's the problem. Documentations says that it will wait until any thread owning the block on the "thread" object will notify.

[Stephan van Hulst]

Documentation also says that wait() may return at any moment, subject to spurious wakeups. It seems that another thread terminating often causes such a spurious wakeup.

This behaviour is not guaranteed to happen though, so the results of that program are undefined.

[Henry Wong]

Vadim Vararu wrote:

John Stark wrote:Hm, for wait() it says 'Causes the current thread to wait until ...'. I guess it is the main thread which is waiting in your code. With the wait() in your code the printout is 999999, so the main thread waits until the Thread 'thread' has finished. If you remove the wait() then the printout is something like '143' on my computer, so execution of the main thread immediately continues after doing thread.start(). Not sure why there is no notify() necessary.

John

That's the problem. Documentations says that it will wait until any thread owning the block on the "thread" object will notify.

What is happening is you are colliding with some other thread that is doing notification -- basically, don't call wait() on the thread object as that is being used internally to implement the join() mechanism.

Use a different object for notifications, and it should work as expected.

Henry

[Mallik Kumar]

You have to obtain a lock on an object rather than a thread.

[Vadim Vararu]

Mallik Kumar wrote:You have to obtain a lock on an object rather than a thread.

Isn't a thread an object?

[Henry Wong]

Vadim Vararu wrote:

Mallik Kumar wrote:You have to obtain a lock on an object rather than a thread.

Isn't a thread an object?

Yes. The Thread instance is an object. And as already mentioned, the problem is that that object is already being used by the library internally for notifications.

Henry