Instances of lazy scheduling and timeslice donation in L4 implementations

Sergio Ruocco sergio.ruocco at
Tue Jan 24 06:00:24 CET 2006

Gernot Heiser wrote:
>>>>>> On Fri, 20 Jan 2006 14:04:03 +0100, "Udo A. Steinberg"
>>>>>> <us15 at> 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.


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:

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 ?



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.

More information about the l4-hackers mailing list