|
Boost : |
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-16 08:20:10
Peter Dimov wrote:
> Johan Nilsson wrote:
>
>>> 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).
>
> It used to be the case that you can't get better than 10ms precision
> on NT without calling timeBeginPeriod, but that was years ago, I
> think (NT 3.5,
> not sure about 4). I'm getting ms-precise timing (not hard realtime,
> obviously, but correct most of the time) on Windows XP.
I'm not so sure. Try out the following (VC compiler) _straight_ after a
clean boot:
--- #include <windows.h> #include <iostream> #pragma comment(lib, "winmm") int main(int argc, char* argv[]) { for (int i = 0; i != 1000; ++i) { std::cout << "MMTime: " << timeGetTime() << '\n'; Sleep(1); } return 0; } --- The minimum interval between the output will be the default timer tick period (10-15ms). Calling timeBeginPeriod(1) before entering the loop will "fix" this. This will not affect the updating of the system time, though. Note that the timer resolution is set "globally" - if one process requests a time period of 1 milliseconds it will also affect other processes' wake-up times. // Johan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk