Object.wait()

[Andersen]

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?

 

[Benji]

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.

 

[Benji]

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.

 

[Thomas Hawtin]

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

 

[Roedy Green]

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.

 

[Andersen]

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?

 

[Roedy Green]

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.

 

[Missaka Wijekoon]

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.

 

[Benji]

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.

 

[Thomas Hawtin]

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.

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

 

[Benji]

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)

 

[Thomas Hawtin]

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