Dmitry Goncharov wrote:
I need to block a thread until either a timeout expires or some other thread wakes this one up. This is really what condition_variable::timed_wait() is for, right? Why can't condition_variable::timed_wait() be used? It can. It has a drawback, though. After the condvar was signaled it has to lock a mutex. This means there is an unbound timeout between the time condvar was signaled and the time condition_variable::timed_wait() returns. Why is that any more unbounded than any other code that has to happen inside the gubbins of binary_semaphore?
After all, something, somewhere, has to wake up and then test to see whether it was timed out or woken up. Which implies a state variable, which implies a mutex to protect it, which implies you're not winning how you think you are.
A binary_semaphore::timed_wait() can be used for the same purpose. The advantage is it doesn't have to lock a mutex.
I think the advantage is that its actually a portable abstraction, in a way that a condition_variable isn't. James