Re: fixed time slices?


"m" <m@xxx>:
There is a significant performance cost to increasing the timer frequency.
No the behaviour is not reliable. There is no deterministic timing on
Windows. Your Sleep(1) is only guaranteed to return after _at least_ 1 ms.
It might not return for hours if the system has something better to do than
run your code. You cannot create a reliable 1 ms sleep with a spin wait
loop either because you may be pre-empted at any time and your code may not
run again for hours.

That's clear.
What I meant with reliability was, if I can count on that the minimum
time a sleep(n) might take is really (n+m+k) ms, where m is the least
valid value passed to timeBeginPeriod(m) and k is some oberhead
value less than m.

I'm not interested in the maximum duration of sleep(), since this can
be easily estimated from system-load and thred priority.

BTW: MSDN says (Sleep function [Base])

"This function causes a thread to relinquish the remainder of its time slice
and become unrunnable for at least the specified number of milliseconds,
after which the thread is ready to run. In particular, if you specify zero
milliseconds, the thread will relinquish the remainder of its time slice but
remain ready. Note that a ready thread is not guaranteed to run immediately.
Consequently, the thread may not run until some time after the specified
interval elapses."

That's clear. But it also says:

| If a higher-priority thread becomes available to run, the system
| ceases to execute the lower-priority thread (without allowing it
| to finish using its time slice), and assigns a full time slice
| to the higher-priority thread.

And that's exactly what I'd need.

My application knows, that it won't be able to do anything useful
for some time, say 1 ms. But after this time, it really shoud
continue. So I set the thread to a higher priority.

The application is mainly standalone, think of a PC game in
fullscreen. Overall, it doesn't matter if the appliction takes up
all CPU resources, but on the other hand it has much better
things/threads to do with that CPU-time than just doing
a brute-force wait.



BTW: A task-switch really is a costly operation even on modern CPUs,
but on the other hand, it's not in general that expenive to talk about
"a significant performance cost to increasing the timer frequency"
if we're discussing a 1ms sleep, meaning at most 4000 additional
task-switches per second
(1000 x ((sleepthread->system->other->system->sleepthread)).

I know that there are many performance implications with small
time slices, many task-switches per time, but on the other hand,
these costs will almost always be much less than using

PROCEDURE bute_force_sleep(ms : dword);
VAR start : Tfloat_double;
BEGIN
start := get_ms_high_precision_time;
while (get_ms_high_precision_time-start)<ms do nothing;
END;



So what is it, you recommend as an alternative?

Gruss

Jan Bruns

.

Loading