Why Object.wait() should always be in a while loop ?
There is a lot of information on the web that waiting thread can be awaken by JVM or
some other code (not written by you anyway ...). How is it possible ?
And secondly, if that can happen, why can't it happen to Thread.sleep() ?
It ceases the thread and puts it into - and here another question: different state ?
Does Object.wait() puts thread to a WAIT state and Thread.sleep() to a SLEEP state
(two different states) ? It that's the case, I would still like to know why
state WAIT can be interrupted and SLEEP not ...
Thanks,
Adrian
# 1
> There is a lot of information on the web that waiting
> thread can be awaken by JVM or
> some other code (not written by you anyway ...). How
> is it possible ?
interrupt(), I bileve.
> And secondly, if that can happen, why can't it happen
> to Thread.sleep() ?
interrupt()
> state WAIT can be interrupted and SLEEP not ...
Sleep can be interrupted. That's why you have to catch InterruptedException.
jverda at 2007-7-12 20:36:02 >
# 2
Hi,
Thanks for the reply.
I know that interrupt() can interrupt ;) My question is:
Why a JVM or some other code can interrupt ?
And as I said, there is a lot of information about
wait() and notify() that if you have a thread which is
waiting, JVM or some other code (not yours) can
notify it. So I'm talking about notify() being called
by JVM or other code rather then interrupt() being
called. So my question remains: why a JVM or some
other code can notify my waiting thread without my
explicit call and it doesn't happen to a sleeping
thread (unless I call interrupt() somewhere in the code ...)
(and that would differentiate state WAIT from SLEEP
if there are these different states at all ...)
Thanks for your patience.
Adrian
# 3
> Hi,
>
> Thanks for the reply.
>
> I know that interrupt() can interrupt ;) My question
> is:
> Why a JVM or some other code can interrupt ?
Why can it? Why wouldn't it be able to? How would interrupt() know whose code is calling it?
Maybe mean why would it? Maybe some other thread wants to tell your thread the app is shutting down and it's time to stop.
> And as I said, there is a lot of information about
> wait() and notify() that if you have a thread which
> is
> waiting, JVM or some other code (not yours) can
> notify it. So I'm talking about notify() being called
Again, how would the VM know who wrote the code that's calling notify()?
>
> by JVM or other code rather then interrupt() being
> called.
Why notify() rather than interrupt()? Because they do two different things.
> So my question remains: why a JVM or some
> other code can notify my waiting thread without my
> explicit call
There would be an explicit call.
> and it doesn't happen to a sleeping
> thread (unless I call interrupt() somewhere in the
Because sleeping is one thing and waiting is a different thing. They serve two different purposes.
jverda at 2007-7-12 20:36:02 >
# 4
jverd, I believe that you are wrong. Object.wait() can return spuriously without a notify() or an interrupt() having taken place. It is for this reason that you are supposed to use the while loop.
This is explicitly in the JavaDoc on the Object.wait() method.
# 5
"Implementations are permitted, although not encouraged, to perform "spurious wake-ups" -- to remove threads from wait sets and thus enable resumption without explicit instructions to do so. Notice that this provision necessitates the Java coding practice of using wait only within loops that terminate only when some logical condition that the thread is waiting for holds."
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.8.1
I have no idea why this is allowed by the JVM specification, but there must be a decent reason.
# 6
> jverd, I believe that you are wrong.
> Object.wait() can return spuriously without a
> notify() or an interrupt() having taken
> place. It is for this reason that you are supposed to
> use the while loop.
>
> This is explicitly in the JavaDoc on the
> Object.wait() method.
Ah, yes. I forgot about that.
jverda at 2007-7-12 20:36:02 >
# 7
> "Implementations are permitted, although not
> encouraged, to perform "spurious wake-ups" -- to
> remove threads from wait sets and thus enable
> resumption without explicit instructions to do so.
> Notice that this provision necessitates the Java
> coding practice of using wait only within loops that
> terminate only when some logical condition that the
> thread is waiting for holds."
>
> http://java.sun.com/docs/books/jls/third_edition/html/
> memory.html#17.8.1
>
> I have no idea why this is allowed by the JVM
> specification, but there must be a decent reason.
Might be to give the VM a relatively clean way to reap "dead" threads?
jverda at 2007-7-12 20:36:02 >
# 8
> Might be to give the VM a relatively clean way to reap "dead" threads?I'd say that's a darn good guess.
# 9
Hi,
Finally I got where I wanted to be ;)
Coming back to my question - that would answer why JVM
can notify my waiting thread (let's assume it has some reasons ...)
Can it happen to a sleeping thread as well ? Or a thread waiting
for a lock ? I understand, that JVM generally could interrupt
all other running threads (can it ?) in case of some serious
circumstances (errors ?), but is it possible to have some spurious
wake-ups for sleeping (waiting for lock) threads ?
Thanks,
Adrian
# 10
> Can it happen to a sleeping thread as well ?
I don't think so. The docs for sleep don't mention it.
> Or a
> thread waiting
> for a lock ?
No, that wouldn't make any sense. It's not the same situation. For sleep and wait, you've explicitly told your thread to stop executing until such time as you decide it's ready to go again, but the VM can supercede that.
For the case of a thread waiting for a lock, you haven't told your thread to stop until you say go. You've told it to go as soon as it can obtain the lock. It will NOT enter that sync block without the lock.
jverda at 2007-7-12 20:36:02 >
