Boost logo

Boost :

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


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