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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe