calling wait outside of loop

[puzzlecracker]

The argument is that calling wait prior to loop me cause a thread never
to be aweken (given that notify[all] has been called prior)

How does waiting in the loop prevent that:

while(a condition){
obj.wait();

}
and notify has been called prior to wait, indefinite sleep is
guaranteed.

what is the argument for calleding after the loop.

thanks

 

[Thomas Hawtin]

The argument is that calling wait prior to loop me cause a thread never
to be aweken (given that notify[all] has been called prior)

How does waiting in the loop prevent that:

while(a condition){
obj.wait();

}
and notify has been called prior to wait, indefinite sleep is
guaranteed.

what is the argument for calleding after the loop.

Are you asking why the following code is not used?

if (...condition...) { // Wrong...
lock.wait();
}

Firstly there is the problem of spurious wakeups. wait can exit at any
time, without reason. Therefore the loop is always necessary.

Even if there were no spurious wakeups, it's still usually wrong.
Typically you may have multiple threads waiting, only one of which can
proceed. Each thread will need to check the notify is for them. For
instance, two threads are waiting to take an element off a blocking
queue, if notifyAll is used both will wake but only one should grab the
new element.

Tom Hawtin

 

[hiwa]

puzzlecracker ã®ãƒ¡ãƒƒã‚»ãƒ¼ã‚¸:

The argument is that calling wait prior to loop me cause a thread never
to be aweken (given that notify[all] has been called prior)

How does waiting in the loop prevent that:

while(a condition){
obj.wait();

}
and notify has been called prior to wait, indefinite sleep is
guaranteed.

what is the argument for calleding after the loop.

thanks

I don't understand your English.

 

[Mitch]

The argument is that calling wait prior to loop me cause a thread never
to be aweken (given that notify[all] has been called prior)

How does waiting in the loop prevent that:

while(a condition){
obj.wait();

}
and notify has been called prior to wait, indefinite sleep is
guaranteed.

what is the argument for calleding after the loop.

thanks

Do you mean that you are calling notify sometimes before the obj.wait()
and its loop are called? If this is the case, when you call notify you
could set a flag boolean notifyCalled = true and in the while loop you
could write while(a condition && !notifyCalled)

But as mentioned before, your English means it is difficult to guess at
what you mean.

 

[Mitch]

The argument is that calling wait prior to loop me cause a thread never
to be aweken (given that notify[all] has been called prior)

How does waiting in the loop prevent that:

while(a condition){
obj.wait();

}
and notify has been called prior to wait, indefinite sleep is
guaranteed.

what is the argument for calleding after the loop.
thanks

Do you mean that you are calling notify sometimes before the obj.wait()
and its loop are called? If this is the case, when you call notify you
could set a flag boolean notifyCalled = true and in the while loop you
could write while(a condition && !notifyCalled)

But as mentioned before, your English means it is difficult to guess at
what you mean.

Actually you would probably write

if(!notifyCalled){
while(a condition){
obj.wait();
}
}

I wrote the previous in a general sense, only to realise that after
posting, it wouldn't actually work.

 

[Gordon Beaton]

Actually you would probably write

if(!notifyCalled){
while(a condition){
obj.wait();
}
}

No. There is already a "real" reason for the notification ("a
condition"), and it should be set by the notifying thread before
notify() is called, within the synchronized block:

synchronized (someObject) {
setCondition(true);
someObject.notify();
}

The waiting thread *must* test for that condition before calling
wait() in every case. This is sufficient to avoid problems caused by
calling notify() prior to wait():

synchronized (someObject) {
while (!getCondition()) { /* until the condition becomes true */
someObject.wait();
}
}

Adding an additional, artifical condition (notifyCalled) gains you
nothing and in fact only distracts from the real condition that is
being communicated between the threads. Understand too the distinction
between a condition stated in terms of the problem domain (e.g. "data
is ready"), and in terms of the implementation ("notify was called").
The latter of these indicates poor design IMO.

The loop is necessary in the case of spurious interrupts, but it also
lets multiple waiting threads contend on a single lock when
notifyAll() is used (and in this case, the condition should likely be
"cleared" by the first waiting thread that discovers the condition).

/gordon