Udo A. Steinberg wrote:
On Tue, 24 Jan 2006 16:00:24 +1100 Sergio Ruocco (SR) wrote: SR> Local experts believe that current L4 implementation(s) do not conform SR> to specification, and Thread B will run only until the next timertick.
Your local experts are correct. In the L4 implementations that I know of B will only run on A's time slice until a higher-priority thread preempts B. I think this is what you meant by "next timer tick" (but note that the next timer tick may wake up a lower-priority thread which does not preempt B - therefore, preemption is what ultimately breaks the donation, not the timer tick per se).
Local experts said 'timertick', but they were busy with other things, so we may want to take a close look at the source and/or ask what they meant exactly. I also found the answer 'timertick' a bit strange, as I would expect donation to be terminated only by:
1) natural end of augmented timeslice 2) preemption by higher-priority thread
Btw., this is the exact same issue as the IPC donation we discussed a few days ago - the kernel does not maintain enough information to restore the donation to B when A's time slice is selected by the scheduler again. - Udo
On the one hand, remember that according to the specification the part of timeslice that A donated to B via L4_ThreadSwitch() *adds* to B's natural timeslice, so the kernel should have provision for this donation-preserving behaviour. Again, a close look to the source seems necessary.
On the other hand, as Gernot pointed out, A's timeslice donation to B when A IPCs to B is simply a *side* *effect* of lazy scheduling, a speed optimisation that avoids to run the scheduler in the IPC path. Being the timeslice donation a mere side-effect, actively carrying it over across preemptions may probably not be the required behaviour.
Sergio