Alexander Terekhov <terekhov <at> web.de> writes:
Anthony Williams wrote:
Alexander Terekhov <terekhov <at> web.de> writes:
Anthony Williams wrote: [...]
Waitable timers. According to the docs, when you specify an absolute timeout for a timer it tracks clock changes.
That isn't really helpful given that win32 waitable timers don't synchronize with condvar waiters by locking associated mutexes.
The point is that a condvar waiter doing a timed wait can use the waitable timer as part of a WaitForMultipleObjects call waiting on the sync objects internal to the cond var, rather than using a timeout: if the waitable timer is triggered then the specified absolute time has been reached, and the call has timed out.
Of course, the condvar implementation then needs to handle relocking the mutexes.
I meant the race between clock change and "WaitForMultipleObjects call waiting".
Here's the flow as it stands at the moment: 1. User calls timed_wait with an absolute time 2. Thread added to waiter list and external mutex unlocked 3. Waitable timer configured for specified absolute time 4. Thread waits for internal notify or timer expiry 5a. if timer expired we're done: relock external mutex 5b. if we were notified, check if it was really us: if so, we're done: relock external mutex 6. If we didn't time out, and the notify wasn't us, loop to 3. Since the waitable timer is tied to the system clock time, the only "race" is if the clock is changed before the timer is configured in step 3. I believe the only issue is if the clock changes multiple times in quick succession. If, for example, the clock is changed back and then forward again, then the timer may or may not expire depending on whether it was configured before or after the forward change. There is no race with WaitForMultipleObjects, as the timer is tied to the system clock. If the timer has expired by the time we wait, then we time out immediately. It might be better to configure the timer once rather than multiple times, but that's not a big deal. Anthony