On Tue, 24 Jan 2006 16:00:24 +1100 Sergio Ruocco (SR) wrote:
SR> THREADSWITCH [Systemcall] SR> The invoking thread releases the processor (non-preemptively) so that SR> another ready thread can be processed. SR> SR> 2) dest != nilthread SR> If dest is ready, processing switches to this thread. SR> In this “extraordinary” scheduling, the invoking thread donates its SR> remaining timeslice to the destination thread. (This one gets the SR> donation in addition to its ordinarily scheduled timeslices, if any.) SR> SR> Since the correctness of some software I am writing may end relying on SR> the behaviour _specified_ at point 2) above, I have the following Q: SR> SR> Do L4 implementations _really_ honour case 2) ? In other words, will SR> Thread B run as long as prescribed by Thread A timeslice ? SR> 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).
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