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