On Sat, Jan 24, 2015 at 7:52 PM, Niall Douglas
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?