[LITMUS^RT] LITMUS-RT Deadline Detection

[Glenn Elliott]

> On May 26, 2015, at 12:25 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> 
>> On 22 May 2015, at 08:51, Geoffrey Tran <gtran at isi.edu> wrote:
>> 
>> 
>> However, I'm not sure I understand how the budget enforcement works to begin with. I tried
>> testing with budget enforcement set to PRECISE.  It looks like when the deadline is missed, 
>> the job number is non-sequential?  Does budget enforcement preempt the job when the budget is
>> exhausted?
> 
> The budget enforcement code is rather simple. All it does is set a timer that expires when the budget is used up. If the timer fires, the task is treated as if it had indicated job completion (i.e., as if it has called sleep_next_period()). As a result, the task is queued on the release queue and will not be eligible for further execution until its budget is replenished when the next “job” is released. 
> 
> Job IDs are still sequential. But if you observe an increment without having called sleep_next_period(), you know that you ran out of budget and are now consuming the budget of the next replenishment. 
> 
> If you are familiar with deferrable servers, precise budget enforcement in LITMUS^RT works as if each task is encapsulated in a deferrable server. Minor difference: if you manually indicate job completion with sleep_next_period(), all remaining budget of the current instance is discarded.
> 
> - Björn

I extended Litmus’s budget enforcement methods quite a bit in my GPUSync fork (https://github.com/GElliott/litmus-rt-gpusync).  One mechanism I added is the ability for a task to receive signal upon budget overrun.  You can use the signal to implement your own application-level on-budget-overrun logic.  For example, you can use siglongjmp() to implement a try/catch design pattern in C, where the catch block implements on-overrun logic.  In C++, you can throw a real exception from the signal handler.  However, this method is fragile since all user-level code must be compiled with gcc’s -fasynchronous-unwind-tables and -fnon-call-exceptions flags.

Unfortunately, my GPUSync fork is about two years out of sync with Litmus.  Also, a large budget enforcement infrastructure had to be built to support some of the more exotic budget enforcement mechanisms—far more complicated than anyone realistically needs.  However, it should be relatively straight-forward to modify today’s Litmus routines that handle budget enforcement to raise a predefined signal for any thread that overruns its budget (if such an approach would be useful).  You just need to make sure that the signal number you use is from Linux's real-time signals range.  This ensures that multiple instances of the same signal do not coalesce into one.  Also, you may have to mask the signal in parts of your user-level code to prevent spurious signals (e.g., during the initialization phase of your task).

-Glenn