Re: fixed time slices?



Hardware timer interrupts can be programmed by the HAL for different
frequency, depending on ExSetTimerResolution. But dispatcher (thread
scheduler) "tick" stays the same. This means that ready-to-run threads of
_equal_ current priority will always be switched at the same intervals.

NEVERTHELESS, as soon as a higher priority thread becomes ready to run, it
will preempt any lower priority thread. Preemption doesn't have to wait
until thread time slice ends. Scheduler "ticks" (relatively constant) only
mean to do time-slicing among same priority threads. Hardware timer
interrupts is what actually fires any scheduled timers and tracks Sleep()
and WFSO() timeouts, and they may have higher (variable) frequency. Some
systems may also provide high-resolition interval timer, spec designed by
Intel around 2002(?).

"m" <m@xxx> wrote in message news:uw328w$tHHA.1768@xxxxxxxxxxxxxxxxxxxxxxx

AFAIK the scheduler does not behave this way but if the scheduler planed a
timer interrupt for a specific delay for the purpose of changing tasks
pre-emptivly, then that is just the end of the low-priority thread's time
slice. In this case, the scheduler would not detect that a higher
priority thread was ready to run, but would _know_ that said thread would
be ready to run and adjusted the time slices of other threads accordingly.



This example only makes sense in the case of simple Sleep(n) calls because
the scheduler can only _know_ when a thread will become ready to run if
there is a fixed or known delay. Since even the relatively simple call
SleepEx(n, true) does not have a fixed or known delay, the scheduler
cannot make any assumptions about how best to optimize the timer
interrupts. Combine this complexity with thousands of threads using tens
of thousands of wait objects in much more complex ways than sleep (like
WFMO and Semaphores, GQCS & IOCP, or Timer Queues) and it is easy to see
why a fixed timer interrupt interval would be the implementation of
choice.




.



Relevant Pages

  • Re: Strange Timer behaviour !!!!
    ... The OAL timer can interrupt at fixed 1ms intervals or dynamically schedule ... the next timer interrupt in the future when the next thread is scheduled to ... I am not able to set the scheduler ... According to msdn document the reschedule period ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [PATCH] x86: Reduce the default HZ value
    ... I think we need to reduce the general tick frequency to be as low as ... frequency with which the timer interrupt disturbs a running application. ... scheduler softirq. ...
    (Linux-Kernel)
  • summary (Re: [patch] prefer TSC over PM Timer)
    ... and attempted to summarize the ... if timer_pm is fixed to read the PM timer only once on non-broken systems ... until/unless C3 and deeper resync tsc then it's best not to default to tsc ... can't be shared with scheduler if we add variable scheduler ticks ...
    (Linux-Kernel)
  • Re: fixed time slices?
    ... | to finish using its time slice), and assigns a full time slice ... become ready to run, and be scheduled on a CPU, when the scheduler is ... response to a timer interrupt or a call to a wait function (maybe other ... a timer-IRQ within wahtevr delay is desired. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: fixed time slices?
    ... high resolution timer(timeBeginPeriod), check ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler planed ...
    (microsoft.public.win32.programmer.kernel)