[Sergio Ruocco]
- 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 ?
Speaking for the Pistachio implementation: The time is accounted to the thread who currently "owns" the timeslice (thread A in this case). Each time a timer tick occurs, and there are no preemptions by higher priority threads, thread B will run on the time donated by thread A. This is according to the spec. Once the timeslice expires a new scheduling decision is made. This may or may not cause thread B to continue running (depending on priorities, scheduling queues, etc.). The "in addition to its ordinarily scheduled timeslices" in the spec does not imply that it will also be the next thread scheduled. It merely means that the time it was donated is not accounted to its own timeslices.
eSk