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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-10-08 09:30:14

Roland Schwarz wrote:
> Peter Dimov wrote:
>> It does matter. Consider the case where two threads are awaiting an
>> element to be pushed into a queue, one uses timed_wait, the other
>> uses wait. The "element pushed" signal arrives concurrently with the
>> timeout, the timed_wait thread is awakened, sees timeout, returns
>> false to its caller, who consequently doesn't pop the element. The
>> other thread waits forever, and the element remains in the queue.
>
> I can see the problem, but you simply would get the wrong result from
> timed_wait, making the caller believe, the operation hasn't timed out.

Well... if you use the wrong specification you'd get the wrong result, sure. 
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.

> I think the caller should do something like:
>
> if (!timed_wait(lk, xt, pred))
> { // handle timeout case
>   if (pred()) {
>     // we got the signal after timeout
>      ...
>   }
>   else {
>     // we received a pure timeout
>   }
> }
> else {
>   // signal received in time
>
> }

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.

> The current definition makes it possible for the user code
> to disambiguate for both cases, while your suggestion would
> drop the timeout information.

User code that tries to disambiguate is broken. You can't depend on a 
timeout not occuring since it's an asynchronous event that you have no way 
to stop. You can, however, depend on a return value of 'true' to tell you 
that the predicate is true, with the change.