Re: wait for process terminate

From: Martin Harvey (Demon account) (martin_at_nospam_pergolesi.demon.co.uk)
Date: 10/12/04 

Date: Tue, 12 Oct 2004 21:03:07 GMT

On Mon, 11 Oct 2004 18:09:17 -0500, Rob Kennedy <me3@privacy.net>
wrote:

>Sleep returns to find that the thread has a brand-new timeslice rather
>than the partial one from before. Is there a way we could test this?

It won't quite work like this - sleep will return to give it the
remainer of it's "timeslice", and the scheduler will be reinvoked at
the appropriate time.

The reason it is very likely to be this way is that the scheduler will
be invoked on a timer interrupt. Giving a thread a "brand new"
timeslice after the use of sleep would require sceduling all further
"timeslices" some fraction of the timer period down.

Not only that, it's probably not a good idea to allow that sort of
behaviour, because an application could concievably steal timeslices
off another if it knew this was the case.... although it would have to
know (or take an educated guess) at the scheduling activity of the
other.

MH.

Relevant Pages

  • Re: using select as a sleep call
    ... the length of the timeslice is a compromise between not spending ... You are confusing timeslice and timer interrupt period. ... kernel space at a timer interrupt is expensive, ... the scheduler will just do ...
    (comp.unix.programmer)
  • Re: wait for process terminate
    ... >is 0 and there are no other qualifying threads waiting to be scheduled. ... >With a non-zero timeout, Sleep will release its timeslice, and it will ... scheduler allocating fixed timeslices - I suspect that the sceduler ...
    (comp.lang.pascal.delphi.misc)
  • Re: [SHED] Questions.
    ... > times / timeslice. ... >> If timeslices did not play a role, then high priority tasks would always ... This happened on Amiga. ... > Yes, like the feedback scheduler... ...
    (Linux-Kernel)
  • Re: is RSDL an "unfair" scheduler too?
    ... That doesnt make my position automatically correct though :-) For example i wrote and maintained the 4g:4g patchset for over 2 years and still that was no guarantee of it making sense upstream;) And it was a hell of a lot of work (much uglier and nastier work than any scheduler hacking and tuning, believe me), and it was thrown away as a cute but unnecessary complication we dont need. ... For example couldnt we introduce per-priority level timeslice quotas in the current scheme as well, instead of the very simplistic and crude STARVATION_LIMIT approach? ... Finally management noted that the peripherals cost three times as much as the CPU, so jobs doing i/o should run first. ... User input was waitio, disk was waitio, response was about as good as it could be for that hardware. ...
    (Linux-Kernel)
  • Re: [patch] CFS (Completely Fair Scheduler), v2
    ... mostly concentrated on bugs, regressions and debuggability. ... scheduler has of CPU hogs. ... Have you tried previous version with the fair-fork patch? ... but I found it was a good compromise over sharing the timeslice with the ...
    (Linux-Kernel)