Re: [boost] Probably bug in condition::timed_wait()

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-08 10:27:22

Peter Dimov wrote:
> Well... if you use the wrong specification you'd get the wrong result, sure. 
Excuse me, I do not understand this sentence.

> The caller can't depend on the operation not being timed out when the return 
> value is true, there is a race between the signal and the timeout and it is 
> perfectly possible for timed_wait to return true after the timeout.

Of course it is possible. But what if the signal was sent in response
to an external event, which was expected to arrive in time?
The program logic then just is wrong because it might be too
late to react to the signal. This is the only place where timed
versions really make sense IMHO. If you just want be able to
cancel the operation I would use the untimed wait and embed a
cancel flag into the pred.

... <snip>example showing disambiguating</snip> ...

> He can, but this kind of defeats the purpose of using the predicate version 
> in the first place. It is supposed to guard against spurious wakeups, so it 
> makes sense to also make it guard against stolen wakeups.

I agree we could change semantics this way, but I still cannot
understand why you think the wakeup is stolen? You have access
to it by evaluating pred.

> User code that tries to disambiguate is broken.

Excuse me, I do not understand this one.
To me code where one thread unconitionally waits while
another timed_waits on the same condition looks even more
broken. (But this is just taste, not sound argument.)

> You can't depend on a 
> timeout not occuring since it's an asynchronous event that you have no way 
> to stop.

I am really not sure if I get your point. Let me try to come
up with an example:

Say we have a thread that makes a call to start an external
device e.g. a motor at time t0. Say we have a second thread
that is monitoring the RPM of the motor and signalling a
condition if it has reached its nominal value. The first
thread meanwhile is waiting on this condition with a timed
wait say t0+t_emergency. Now lets assume motor specs. dictate
it is essential to immediately stop the device if it hasn't
reached nominal RPM within t_emergency. Doesn't your
proposed change just hide this fact, and the motor thus
might break?

I think the question is which information is of greater
importance to the program: expired timeout or missed
signal.

But again, I think I possibly cannot see your point clear
enough yet. Can we agree that the current version is not
wrong? You are just suggesting a possibly better less
error prone semantics? If so please try to elaborate it
a little more.

Roland