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. 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 } or the following which is equivalent to your suggestion: if (!timed_wait(lk, xt, pred) && !pred()) { // handle timeout } The current definition makes it possible for the user code to disambiguate for both cases, while your suggestion would drop the timeout information. Does this make sense? However the issue should be cleary documented. Roland