It's not a secret anymore!
The moose likes Beginning Java and the fly likes notify() effects on both threads that have/haven't called wait() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "notify() effects on both threads that have/haven Watch "notify() effects on both threads that have/haven New topic

notify() effects on both threads that have/haven't called wait()

Pierluigi Di Giacomo

Joined: Jan 18, 2012
Posts: 13
Hello Ranchers,

I'm experimenting on threads for the OCPJP6 exam. I've read the description of the notify() method of class java.lang.Object, and there's a point that it's not much clear to me:
The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.

1)Does this mean the following ?
If two threads t1 and t2 are running and t1 calls wait() on a lock "l", and t2 is already waiting on l (it's stopped just before a synchronized(l){} block), then when a thread t3 calls l.notify() it will restore t1 from the blocked state into running. Here, it may cause either t1 or t2 to continue execution without favoring t1 (i.e. the awakened thread) in any way.

I wrote a small program to test this behavior, but it is inconsistent with what stated by the description, in that the awakened thread seems always choosen instead of the other one simply waiting on a synchronized block.
2) So, where is my mistake in this code ?

Here, three threads are instantiated and executed on the fly and sequentially by the main thread. Each have a block synchronized on the same lock (namely, the instance of the outer class that created the threads). The aim of this is to call notify() on a lock that is conteded by a just-awakened thread and a thread waiting on a synchronized block.
The first thread gets the lock, then calls wait() and releases it. Now it's blocked and waiting that some other thread calls notify(); in the meantime, the second thread gets the lock and goes to sleep for 1 second; by the time it calls notify() the third thread will be already waiting on a syncronized block, so the call to notify() will happen in the scenario described in 1).
Steve Luke

Joined: Jan 28, 2003
Posts: 4181

It is nearly impossible to prove or disprove this sort of thing. The comment you quote says there is no guarantee one way or another as to which thread might get the lock next. Implementation details of a particular OS, JVM version, or just plain luck may indicate otherwise - and in your testing environment which is much simpler than any real world scenario, you are getting what looks like consistent behavior. But that behavior can and will change when the number of threads change, the version of the JVM changes, etc... The quote tells you that you can not rely on any type of expected behavior. The conclusion is, if you need to ensure one thread gets access to the lock before another one then you must code that behavior yourself to ensure it behaves reliably.

I agree. Here's the link:
subject: notify() effects on both threads that have/haven't called wait()
It's not a secret anymore!