Instances of lazy scheduling and timeslice donation in L4 implementations

[Udo A. Steinberg]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20060124/d7d07fd7/attachment-0001.asc>