Re: [boost] [thread] Timed waits in Boost.Thread potentiallyfundamentally broken on Windows (possibly rest of Boost too)

Subject: Re: [boost] [thread] Timed waits in Boost.Thread potentiallyfundamentally broken on Windows (possibly rest of Boost too)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-01-24 13:29:35

On Sat, Jan 24, 2015 at 7:52 PM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> On 24 Jan 2015 at 18:01, Peter Dimov wrote:
>
>> > If anyone has a problem with this solution, now is the time to speak.
>>
>> I do.
>
> You may not be aware that Thread already substantially manipulates
> the timeout sent to Windows. Firstly it converts any input
> timeouts/deadlines into a steady_clock deadline. That enters the
> Win32 implementation. This code then extracts a DWORD millisecond
> timeout interval suitable for feeding to Windows. If that timeout is
> 20 ms or higher, it takes a code path based around deadline
> scheduling kernel objects via CreateWaitableTimer. If that timeout is
> 19 ms or less it feeds it directly to the kernel wait composure
> routine.
>
> The problem with the above strategy is that it was clearly designed
> around when Windows had a fixed tick interval of 10ms multiples, the
> kernel didn't coalesce timers and the kernel wasn't tickless.

I'm not sure if that was done so in account for a specific time quant
duration. My understanding is that this was mainly done for two
reasons. First, to make shorter waits more efficient. Second, waitable
timers take into account system time shifts, which is more important
for longer waits. FWIW, as I remember Windows quant duration is
adjustable both by user and application and by default on desktop is
about 15 ms. So it makes little sense to aim for a specific quant
value, much less a multiple of 10 ms.

The optimization for shorter waits may not be relevant anymore, but in
order to make the change for use of waitable timers for all absolute
waits one should conduct some performance tests.

And there's another consideration. Waitable timers are useful for
absolute waits. For relative waits I would still like Boost.Thread to
use relative system waits. The reason is that relative waits do not
react to system time shifts and do not require a waitable timer kernel
object.

> What I'm planning to do is very simple: we always use deadline timer
> scheduling from now on, so quite literally the steady_clock deadline
> that comes in is exactly that handed to Windows unmodified. I was
> also going to try setting a tolerable delay via SetWaitableTimerEx()
> on Vista and later where the tolerable delay is calculated as 10% of
> the interval to the deadline but clamped to:
>
> timeGetTime() <= tolerable delay <= 250 ms

I'm not sure I understood this. timeGetTime() returns system time
since boot. Did you mean that you would somehow discover the quant
duration and use it for the tolerable delay?