[kaffe] about wait and notify

[Chris Gray]

On Monday 24 November 2003 09:02, Luca Ferrari wrote:
> Hi to everyone,
> I've got a doubt about the behaviour of wait/notify methods at the JVM
> level. This doubt came in my mind after I noticed a misbehaving program
> which was using such methods. By the way here's the problem: running a
> program which executes a notify() call on a monitor, I noticed two
> different behavior between kaffe and sun JVM. While the former (1.0.5)
> executes rightly, that means suspend the notifier thread and resume waiting
> threads just after the notify call, the latter didn't: it continued the
> execution of the notifier thread untill re-schedulation.
> Now I'd like to know if this is true (i.e., the two JVMs act differently on
> thread synchronization) and is a design aspect. If so can anybody tell me
> why there's this difference?

Kaffe's behaviour is correct. See 
<http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#notify()>:

<!-- begin quote -->

public final void notify()

Wakes up a single thread that is waiting on this object's monitor. If any 
threads are waiting on this object, one of them is chosen to be awakened. The 
choice is arbitrary and occurs at the discretion of the implementation. A 
thread waits on an object's monitor by calling one of the wait methods.

The awakened thread will not be able to proceed until the current thread 
relinquishes the lock on this object. 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. 

This method should only be called by a thread that is the owner of this 
object's monitor. A thread becomes the owner of the object's monitor in one 
of three ways: 

By executing a synchronized instance method of that object. 
By executing the body of a synchronized statement that synchronizes on the 
object. 
For objects of type Class, by executing a synchronized static method of that 
class. 

Only one thread at a time can own an object's monitor.

<!-- end quote -->

Read the second paragraph very carefully!

If Sun's VM is behaving exactly as you describe then they're not according to 
spec. However I suspect that this is not the case: if you put a sleep(10000) 
after the notify() you should see that the waiting thread is indeed blocked 
until the notifying thread leaves the synchronized block.

Different implementations of the monitor construct can differ in the way they 
handle competition between threads of equal priority. Giving preference to 
threads which have just woken from a wait(), at the expense of any thread 
which just called notify(), is a possible policy but it's not the only one. 
Correctly written code which uses monitors schould not depend on details such 
as this.

So you may have found a bug in Sun's monitor handling; you almost certainly 
have a bug in your code; but Kaffe appears to be doing the Right Thing. IMHO.

Regards

Chris Gray