[LITMUS^RT] Supporting Job Aborts

[Glenn Elliott]

On Sep 7, 2012, at 4:14 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> On 07.09.2012, at 21:29, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> 
>> It sounds like the kernel still has to be modified to perform the budget changes.
> 
> For what you described initially (signal on budget overrun), no. For slack donation, yes of course. But it's likely a lot easier than introducing new signals and hacking / removing the user space trampoline.
> 
>> How does the kernel know which timer instance associated with a task is the one that the task set up, at the application level, to perform the budget timing?  In all likelihood, there would just be one timer (especially just one with the ITIMER_VIRTUAL), but we still can't be entirely sure, right?
> 
> That's why I said I'd flag the timer as being special. Of course, no such support exists in standard Linux and would have to be added. Still, that's likely not that hard—just add a setitimer2() syscall that takes an additional flags parameter and proxies the rest to the normal itimer machinery.
> 
> Anyway, I probably don't fully understand what you have planned with this in the long term; my point is mainly that similar mechanisms already exist and that hacking them is likely simpler than doing low-level signal delivery work.
> 
> - Björn


Ah, I see.  That does make sense.  It doesn't sound all that complicated either.

However, I do already have a version job aborts with Litmus-signals working.  I believe it is enough to move forward with my work.  I fully realize that this stuff might not be merged into Litmus for the reasons discussed earlier.

If you're interested in seeing what I have done, I have pushed "prop/litmus-signals" branches to both litmus-rt and liblitmus on github.

Using all the input I received, I settled on the following design:
1) Litmus signals overlap with SIGRTMIN/MAX.  This allows us to avoid having to mess with signal trampolines or extern private functions!  No more hacks!
2) Tasks can handle/ignore/block/unblock Litmus signals.
3) TRY/CATCH supported by using sigsetjmp()/siglongjmp(). (All done in liblitmus-- see rtspin for example usage.)  I think this code can be reused with Björn's suggested itimer approach.  If you want to know more about the technique I used, see: http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html.  Note that I use the sig* variants of setjmp/longjmp.  This allows the signal masks to be restored when I jump from the signal handler (a received signal is usually blocked within the signal handler-- siglongjmp() unblocks it).
4) Real-time tasks select a budget signaling policy, similar to how budget enforcement policy is selected.  I originally planned on inspecting whether signal handlers were registered to various litmus signals to determine whether or not signals should be sent.  However, this technique alone isn't enough to determine whether the user wants budget signals delivered precisely (hrtimer) or on quantum boundaries.  In any case, this approach makes budget signals and budget enforcement orthogonal.  Also, in the case of precise signals, the existing hrtimer used for budget enforcement is reused/piggy-backed.
5) C++ exception signal wrappers (when litmus.h is included in a file compiled when __cplusplus is defined).  Unfortunately, there is a race condition hidden in here.  With setjmp()/longjmp(), I can inspect a custom setjmp/longjmp-stack to see if the longjmp will be handled if it is called-- longjmp is not called if the stack is empty.  There is currently no way to know if a signal handler has been invoked while the real-time task is in a try/catch block.  Anyway, there is a chance that an exception can be thrown while the real-time task is outside of the try/catch block.  This occasionally results in an uncaught-exception crash.  I have a work-around in mind, but will hold off for now.

Thanks for all your useful advice!

-Glenn

p.s. I'll push the final changes for EDF tie-breaking tomorrow.