Re: [boost] Low-level precision timer proposal

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-16 07:07:00

Peter Dimov wrote:
> Johan Nilsson wrote:
>
>> My guess is that a monotonic timer solution based on QPC/QPF should
>> be good enough for at least 90% of all applications.
>
> People (game programmers) have been repeatedly running into problems
> with
> QPC in practice. It may be good enough for 90% of the _cases_, but if
> your _application_ depends on QPC for accurate timing, it can break
> and you may get a baffling bug report.

Of course. If someone needs accurate timing under Windows that should work 
everywhere, QPC is probably not the way to go. So don't use e.g. 
boost::timer<performance_counter> in this case - roll your own. A 
performance counter based implementation should still be usable for a large 
audience. If milliseconds is enough - perhaps the mmlib functionality is 
good enough (I have too little experience with that).

Just out of curiousity - do you know if the performance counter was 
tsc-based, PIT-based, or whatever in the mentioned problem cases above?

>
>>> We don't have a good TIME_MONOTONIC solution, and we really do need
>>> one for the threading library.
>>
>> I guess the TIME_MONOTONIC stuff would mostly be used for sleep(). As
>> there is no way to explicitly make a thread sleep less than the clock
>> tick under Windows[*] - why do we need a high-res monotonic counter
>> solution for the thread library? Or did I misunderstand you
>> (probably)?
>
> We need a monotonic time for condition::wait. It may not be high
> resolution (depending on your definition of high), it just needs to
> work reliably,
> which the current xtime implementation does not.

Sorry for being vague. I didn't see much of a point being able to specify a 
condition wait time with a microsecond resolution, when systems generally 
aren't capable to wake up the waiting thread in a shorter time than decided 
by the tick rate of the system.

OTOH, if you can't specify a microsecond wait time you'll never be able to 
use this on platforms that provide this functionality (haven't seen one 
myself though).

>
> I'm not sure which clock do you mean when you say that a thread can't
> sleep for less than a clock tick. If you mean the CPU clock, then
> yes, a no-op Sleep function that returns immediately would probably
> consume more than one clock tick, so it is impossible to make a
> thread sleep for less.

I referred to the timer tick period (~10-15 ms for the NT family).

// Johan