AW: What happens on timeslice overrun?

Rene Wittmann wittmaennle at
Fri Sep 23 17:48:51 CEST 2005


> From the example code you posted it doesn't look like you 
> made the variable that is shared between the two threads 
> "volatile". Only when that variable is volatile will the 
> compiler read it from memory every time. Otherwise it is free 
> to cache the variable in a register and may not see the write 
> from the other thread.
> But that's not the real problem here.

OK, I changed my variables to volatile, but as you said: it's not really the

> What you want is an atomic way of checking for a deadline 
> miss and acting upon the result of that check. But such 
> functionality does not exist. There is currently no way you 
> can prevent the above scenario where the deadline miss occurs 
> after the check but before (or while) you go to sleep via next_period.
I think for l4_rt_next_reservation there is such a "check" in the kernel by
passing the timeslice number you think you're on as argument to this call.
Maybe one could include such functionality for l4_rt_next_period by passing 
the period you're waiting for as argument. This would give a quite useful 
improvement :-)
> So what you have to do instead is: upon detecting a deadline 
> miss, the preempter thread should ex_regs the thread with the 
> deadline miss (thereby cancelling the l4_rt_next_period/IPC 
> operation). When you return from next_period, you can check 
> if you've been ex_regs'd out of it or whether the call 
> returned regularly at the beginning of your new period, e.g, 
> by checking the global variable that you already have.
But if I detect it right after returning from l4_rt_next_period, it's
too late. One could say: skip the next call, but this would in worst case
lead to an execution time 50% longer than the expected one (skip every
l4_rt_next_period). That's a great pity!


More information about the l4-hackers mailing list