Re: fixed time slices?

Nothing changed in system scheduling for all the processes, except those set
high resolution timer( timeBeginPeriod ), check
http://www.microsoft.com/technet/sysinternals/information/HighResolutionTimers.mspx
Arkady

"Jan Bruns" <testzugang_janbruns@xxxxxxxx> wrote in message
news:4681fa9b$0$14873$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
But the actual behaviour on my computer is diffrent from that.

WF?O and Sleep seem to only return on the beginning of a new
time-slice, except if the event already was signaled on the call.
If the event wasn't signaled, lower priority threads get to run,
and aren't interupted until the end of their slice.

On my computer,

setThreadPriority(realtime); for i := 1 to 1000 do sleep(1);

takes 1000*tick_period to run (normally 15s). This also applies
to WFSO using an event that gets signaled just *after* WFSO
started to block execution.

If I call timeBeginPeriod(1) before the above sniplet, it takes
only about 2 seconds to run, instead of 15, and the same thing
applies to WFSO again, if the event was set 1ms after WFSO
starts to block execution.

So obviously the mmTimer HAL has influence on the kernel's
scheduling intervalls.

This doen't mean that "slice" in the sense of overall dividing
CPU-resources to threads changes.

Gruss

Jan Bruns









"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> schrieb im Newsbeitrag
news:eqwzbEHuHHA.1120@xxxxxxxxxxxxxxxxxxxxxxx
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: fixed time slices?
    ... Implementation of KeWaitFor* and KeSetEvent (and other signals) doesn't ... This hasn't anything to do with hardware's timer resolution ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler ...
    (microsoft.public.win32.programmer.kernel)
  • Re: fixed time slices?
    ... Sleep(1) will sleep at least one hardware timer tick, ... 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)
  • Re: fixed time slices?
    ... This hasn't anything to do with hardware's timer resolution ... 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)
  • 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)
Loading