Peter Dimov wrote:
John Maddock wrote:
Silex wrote:
I found out that there's already <boost/date_time/microsec_time_clock.hpp>, but on windows it uses GetSystemTimeAsFileTime().
This raises a potential issue: I don't know if GetSystemTimeAsFileTime() works at millisecond resolution like QueryPerformanceCounter() does, and I don't know if QueryPerformanceCounter() returns some kind of epoch.. the docs are rather lowly-documented on this.
Ah, I suspect there may be problems with the CPU clock changing speed with some of these timers, I'm not sure though...
The problem with GetSystemTimeAsFileTime is that it can jump an hour forward/backward as DST kicks in/out.
The problem with QueryPerformanceCounter is that QueryPerformanceFrequency is not (AFAIK) required to return the same value every time. It may be CPU clock based, and a low power CPU can vary its frequency depending on load.
I guess that's true. However I seem to recall that the Linux 2.4 kernel based gettimeofday on rdtsc, so I wonder how reliable gettimeofday really is on portable computers. Perhaps some other implementation is selected for certain platforms. The QPF docs state that the frequency never change while the system is running, which is rather ambiguous. The word "frequency" could simply refer the value returned by QPF and not the actual hardware counter; "while the system is running" might, or might not include going back and forth to/from sleep mode/hibernation. For uniprocessor systems QPC is most often not rdtsc-based, so those should pose lesser problems. My guess is that a monotonic timer solution based on QPC/QPF should be good enough for at least 90% of all applications. It's not the ultimate, but a library could provide a class parameterized on the actual implementation (boost could provide the QPC / gettimeofday implementations out-of-the-box as the default values under the different platforms). This, in combination with providing a disclaimer that explains the limitations under Windows, should be sufficient. People needing better than this could roll their own implementation. As for implementing a high-res calendar time provider under Windows - I frankly think that it's next to impossible to implement a general-purpose implementation that works for the all the different possible hardware configurations. Perhaps a custom driver would make it possible. For specific hardware configurations I _do_ think it's possible - but I still wouldn't leave any guarantees until after doing some system-specific testing and verification. Perhaps not even then - it is hard to test whether the results are actually correct or not.
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)?
FWIW, I have found timeGetTime pretty reliable on Windows as a monotonic time provider. It only has 1ms resolution, though.
That might very well be a good solution. OTOH, I've never had any problems with using QPC myself. Just my 0.02EUR. // Johan [*] Ok, not strictly true: - Sleep(0) causes a yield which _could_ return within a clock tick if no other threads are in the ready state. But that's not strictly a sleep. - A thread waiting for I/O will be activated whenever the I/O is completed (normal restrictions apply with regards to priorities etc).