Gernot Heiser wrote:
On Fri, 20 Jan 2006 14:04:03 +0100, "Udo A. Steinberg" us15@os.inf.tu-dresden.de said:
You imply that donation across preemptions is the "correct" behaviour. This is at least debated. In fact, the original motivation is not at all to donate a time slice, but to do lazy scheduling,
A different slant on 'proper' timeslice donation.
Situation:
Thread A has a 'very long' timeslice (set by L4_Schedule()), and is currently running on the CPU.
Thread B has a standard timeslice, is active (ready), but not running, not because is blocked on IPC, but just because it has a priority lower than A.
Thread A ... L4_ThreadSwitch ( Thread B ); ...
According to these L4 specifications:
http://l4hq.org/docs/manuals/l4-x2-20051021.pdf http://www.ertos.nicta.com.au/software/kenge/pistachio/latest/refman.pdf
-------------------------------------------------------- THREADSWITCH [Systemcall] The invoking thread releases the processor (non-preemptively) so that another ready thread can be processed.
Input Parameter
1) dest == nilthread Processing switches to an undefined ready thread which is selected by the scheduler. (It might be the invoking thread.) Since this is “ordinary” scheduling, the thread gets a new timeslice.
2) dest != nilthread If dest is ready, processing switches to this thread. In this “extraordinary” scheduling, the invoking thread donates its remaining timeslice to the destination thread. (This one gets the donation in addition to its ordinarily scheduled timeslices, if any.) ... --------------------------------------------------------
Since the correctness of some software I am writing may end relying on the behaviour _specified_ at point 2) above, I have the following Q:
Do L4 implementations _really_ honour case 2) ? In other words, will Thread B run as long as prescribed by Thread A timeslice ?
Local experts believe that current L4 implementation(s) do not conform to specification, and Thread B will run only until the next timertick.
Comments ?
Sergio