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