[boost] Re: problems with boost::thread

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2004-04-19 10:54:51

Russell Hind <rhind_at_[hidden]> writes:

> Anthony Williams wrote:
>> On Windows, you could use GetTickCount to do the timing, with
>> GetSystemTimeAsFileTime and SystemTimeToFileTime to get the limits --- e.g.
>> const SYSTEMTIME suppliedEndTime=...;
>> FILETIME endTime={0};
>> SystemTimeToFileTime(&suppliedEndTime,&endTime);
>> FILETIME startTime={0};
>> GetSystemTimeAsFileTime(&startTime);
>> DWORD const initialTick=GetTickCount();
>> ULONGLONG const diff=reinterpret_cast<ULARGE_INTEGER const&)(endTime).QuadPart-
>>         reinterpret_cast<ULARGE_INTEGER const&)(startTime).QuadPart;
>> ULONGLONG const elapsedTicks=diff/10000;
>> ASSERT(elapsedTicks<=ULONG_MAX);
>> while((GetTickCount()-initialTick)<elapsedTicks)
>> {
>>     doStuff();
>> }
>>
>
> TickCount can wrap around, though (I think its something like 47.9 days or
> something like that).

Yes, that's what the ASSERT checks. How often do you schedule a software event
for 40+ days into the future?

> There is also QueryPerformanceCounter for high resolution tick count,
> QueryPerformanceFrequency will give you the frequency of the counter as it
> will vary from system to system.

Yes. I expect that the wrap-around for that is longer, since it is
64-bit. Even if it is set to the processor speed, on a 4Ghz CPU you would
still have 2^32 seconds, which is a good few years. I can't imagine there are
any systems where the resolution is better than the CPU frequency (what good
would it do?). There doesn't seem to be any comment about the minimum
resolution, but I guess it should be at least as good as GetTickCount,
otherwise it wouldn't qualify for High Performance.

It's slightly more work to use due to the system variability, but not a lot.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.