Object.wait()

Thread view:

Andersen - 10 Dec 2005 18:11 GMT

Doesn't Object.wait() imply that the JVM will yield the thread? I was
assuming that and was disappointed when I found that this not
necessarily the case?

Reply to this Message

Benji - 10 Dec 2005 18:36 GMT

> Doesn't Object.wait() imply that the JVM will yield the thread? I was
> assuming that and was disappointed when I found that this not
> necessarily the case?

It will yield in most cases. If the thread has previously been inturrupted,
it will throw an inturrupted exception...

your question is strange. It looks like you're asking if you were
disappointed when you found out that it's not necessarily the case. =P

in what cases did you find that it won't yield the thread? it will in all
normal cases.

Signature

Of making better designs there is no end,
and much refactoring wearies the body.

Reply to this Message

Benji - 10 Dec 2005 18:37 GMT

> Doesn't Object.wait() imply that the JVM will yield the thread? I was
> assuming that and was disappointed when I found that this not
> necessarily the case?

It will yield in most cases. If the thread has previously been killed,
it will throw an inturrupted exception...

your question is strange. It looks like you're asking if you were
disappointed when you found out that it's not necessarily the case. =P

in what cases did you find that it won't yield the thread? it will in all
normal cases.

Signature

Of making better designs there is no end,
and much refactoring wearies the body.

Reply to this Message

Thomas Hawtin - 10 Dec 2005 20:03 GMT

> It will yield in most cases. If the thread has previously been killed,
> it will throw an inturrupted exception...

You mean, if the thread has previously been interrupted. It may also
throw any pending asynchronous exceptions, or an
IllegalMonitorStateException if it is not within a synchronised block.
Theoretically it can spuriously wake at any point, although Sun's
implementations apparently do not do this for backward compatibility.

My guess is that the original poster made some subtle error.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Roedy Green - 10 Dec 2005 22:08 GMT

On Sat, 10 Dec 2005 19:11:04 +0100, Andersen
<andersen_800@hotmail.com> wrote, quoted or indirectly quoted someone
who said :

>Doesn't Object.wait() imply that the JVM will yield the thread? I was
>assuming that and was disappointed when I found that this not
>necessarily the case?

here's the JavaDoc on wait. I think you missed three important points.

Causes current thread to wait until another thread invokes the
notify() method or the notifyAll() method for this object. In other
words, this method behaves exactly as if it simply performs the call
wait(0).

The current thread must own this object's monitor. The thread releases
ownership of this monitor and waits until another thread notifies
threads waiting on this object's monitor to wake up either through a
call to the notify method or the notifyAll method. The thread then
waits until it can re-obtain ownership of the monitor and resumes
execution.

As in the one argument version, interrupts and spurious wakeups are
possible, and this method should always be used in a loop:

synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}

This method should only be called by a thread that is the owner of
this object's monitor. See the notify method for a description of the
ways in which a thread can become the owner of a monitor.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

Andersen - 11 Dec 2005 00:21 GMT

> synchronized (obj) {
> while (<condition does not hold>)
> obj.wait();
> ... // Perform action appropriate to condition
> }
>

Yes Roedy, I am well aware of all this that you are saying, and I am
using it in synchronizing access to a critical section.

I am wondering about side-effects that have to do with
context-switching. Is Object.wait() causing the OS native thread to yield?

Reply to this Message

Roedy Green - 11 Dec 2005 01:07 GMT

On Sun, 11 Dec 2005 01:21:55 +0100, Andersen
<andersen_800@hotmail.com> wrote, quoted or indirectly quoted someone
who said :

>Is Object.wait() causing the OS native thread to yield?

I would expect so. You can expect the OS to do a context switch at
any sort of wait or when your timeslice is up or possibly even any
time there is an interrupt other than a trivial one.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

Missaka Wijekoon - 11 Dec 2005 01:55 GMT

> I am wondering about side-effects that have to do with
> context-switching. Is Object.wait() causing the OS native thread to yield?

That probably depends on the implementation, OS and JDK version and a
boat load of other factors. It is possible that a Java thread may not
be directly mapped to an OS thread. If my application thread (or some
other process in the OS) was runnable, then I would hope that
Object.wait() does induce a context switch.

Reply to this Message

Benji - 11 Dec 2005 05:50 GMT

> I am wondering about side-effects that have to do with
> context-switching. Is Object.wait() causing the OS native thread to yield?

What do you expect will happen? It will just spin in a loop taking up 100%
of the CPU? Either it will perform computations, or it will yield - those
are the only two choices for a program. It's not going to spin-lock if
that's what you're asking.

Signature

Of making better designs there is no end,
and much refactoring wearies the body.

Reply to this Message

Thomas Hawtin - 11 Dec 2005 19:10 GMT

>>I am wondering about side-effects that have to do with
>>context-switching. Is Object.wait() causing the OS native thread to yield?
[quoted text clipped - 3 lines]
> are the only two choices for a program. It's not going to spin-lock if
> that's what you're asking.

Cases where it makes sense to poll are conceivable. If a thread holds a
lock and another hardware thread running on the same chip is attempting
to acquire it, then the second lock may poll in the expectation that the
holding thread will release lock any nanosecond. Following that line of
reasoning, the code for wait could expect a hardware thread polling for
the lock to notify almost immediately. However, I don't know of any
implementations that do the latter.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Benji - 11 Dec 2005 19:23 GMT

> Cases where it makes sense to poll are conceivable. If a thread holds a
> lock and another hardware thread running on the same chip is attempting
> to acquire it, then the second lock may poll in the expectation that the

this isn't locking, this is object waiting. in order for it to make sense
to poll, you would have to know that the other thread is about to signal -
and you can't know that. You're thinking of other types of locking
situations. (for example, a synchronized block may not yield right away in
certain circumstances)

Signature

Of making better designs there is no end,
and much refactoring wearies the body.

Reply to this Message

Thomas Hawtin - 11 Dec 2005 20:51 GMT

>>Cases where it makes sense to poll are conceivable. If a thread holds a
>>lock and another hardware thread running on the same chip is attempting
>>to acquire it, then the second lock may poll in the expectation that the
>
> this isn't locking, this is object waiting.

By "this is" you mean "this thread is about"? My next sentence, deleted
from the quote, follows onto the subject.

> in order for it to make sense
> to poll, you would have to know that the other thread is about to signal -
> and you can't know that. You're thinking of other types of locking
> situations. (for example, a synchronized block may not yield right away in
> certain circumstances)

If a lock is being used to wait, it's a reasonable guess that some other
thread(s) are using it to notify. Other threads using it to wait are
probably going to drop into the wait and release the lock pretty much
immediately. I guess you could use a lock for wait/notify and also for
other bits of exclusion, but I that probably falls under the category of
bad coding.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Object.wait()

Free Magazines