Thread wait

[Rams Senthiil]

I found a thread issues notify didnt invoke the waiting thread immedeatly, instead the same thread which issues notify keep on running until it executes few statements. I thougth once a notify is executed it should immedeatly transfers control to any waiting thread.I think each thread is alloted with a paricular time slice, until that time slice is over thread will keep on running even it issues notify or wait--- i am not sure, can any one help me?

[Peter den Haan]

Originally posted by Rams Senthiil:
I found a thread issues notify didnt invoke the waiting thread immedeatly, instead the same thread which issues notify keep on running until it executes few statements. I thougth once a notify is executed it should immedeatly transfers control to any waiting thread. [...]

Well, for a start, it can't, because the notifying thread still holds the monitor lock. The JLS says the following about it:
"Every object, in addition to having an associated lock, has an associated wait set, which is a set of [waiting] threads. [...] Wait sets are used by the methods wait, notify, and notifyAll of class Object. These methods also interact with the scheduling mechanism for threads. [... A waiting] thread T then lies dormant until one of three things happens:

Some other thread invokes the notify method for that object and thread T happens to be the one arbitrarily chosen as the one to notify.

Some other thread invokes the notifyAll method for that object.

If the call by thread T to the wait method specified a timeout interval, the specified amount of real time has elapsed.

The thread T is then removed from the wait set and re-enabled for thread scheduling. It then locks the object again (which may involve competing in the usual manner with other threads) [...]"
So notify() merely re-enables a waiting thread for scheduling; it will first has to compete for the object's monitor lock, and then it can still take a while for it to get its time-slice.
- Peter
[ February 07, 2003: Message edited by: Peter den Haan ]

[Jim Yingst]

Well, for a start, it can't, because the notifying thread still holds the monitor lock.
And because of this, any program that invokes notify() or notifyAll() should usually try to give up the lock as soon as possible after notifying. Either exit the synchronized block/method that you're in, or invoke wait() on the monitor whose lock you need to give up. (Assuming you're also going to eventually notify() the current thread when it can resume.) Otherwise you're just wasting the thread scheduler's time.
[ February 07, 2003: Message edited by: Jim Yingst ]

[Rams Senthiil]

Thank you, What about time slice is there any such a thing for java threads?

[Jim Yingst]

Some Java implementations use time-slicing; some don't. Most Java code should make no assumptions about whether time-slicing is used or not. In this example it doesn't really matter - after notify() is exacuted, the notified thread can't actually execute until the notifying thread releases the lock. Period. It doesn't matter if time-slicing interrupts the notifying thread and tries to run the notified thread - if the lock is not yet available, the notified thread will be unable to do anything. The time-slicing implementation will then have to switch over to a different thread, or perhaps (hopefully) back to the original notifying thread, which still has work to do before it releases the lock.

[Rams Senthiil]

Thankx JIM.