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 problem.
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 already 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 second l4_rt_next_period). That's a great pity!
Regards, Rene