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 -- -- http://www.cse.unsw.edu.au/~sruocco/ ERTOS Researcher Lecturer National ICT Australia Ltd. University of New South Wales This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed.