AW: What happens on timeslice overrun?
wittmaennle at gmx.de
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
> 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