Boost logo

Boost :

Subject: Re: [boost] [thread] Timed waits in Boost.Thread potentiallyfundamentally broken on Windows (possibly rest of Boost too)
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-24 11:01:18


Niall Douglas wrote:

> After sleeping on it for a night, this is what I'll do: I'm going to
> update Thread's clamping of timeouts to better match Windows since Vista
> onwards. This basically means asking Windows what its current scheduling
> quantum is (it can vary from moment to moment according to what
> applications request) and clamping the timeout sent to Windows APIs to
> that quantum. Therefore, if you asked for a 10ms timeout, Thread will
> clamp that probably to 15 ms before sending it onto Windows. I'll always
> round upwards, so there is a greater potential for a timed wait to take
> one quantum longer than it should before timing out, but then that can
> happen anyway at any time.

...

> If anyone has a problem with this solution, now is the time to speak.

I do.

The point of the timeout waits is that you have a deadline. On a
non-realtime OS, this deadline can never be absolute, but it still makes no
sense for the library to deliberately arrange things so that this deadline
will never be met.

You have no business changing the timeout value that the user has given you.
Your task is to tell the kernel what the user wants. What the kernel does
with this information is its own business and its responsibility.

It's not just the size of the quantum that matters, but also where in the
quantum the thread is at the moment it makes the sleep call. The kernel
knows that it would make no sense to wake up a thread and then immediately
context-switch away from it, so it arranges things to avoid this by either
waking it up earlier, so that it has a portion of the quantum still
available, or later, at the start of the next quantum. Sometimes 'earlier'
is closer to what you asked, so it wakes you up earlier. This is exactly how
it must be.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk