[kaffe] about wait and notify
Chris Gray
chris@kiffer.eunet.be
Mon Nov 24 01:49:02 2003
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