Managing RTOS Scheduler Latency During Interrupts

In this lesson, you will learn how nested interrupts and critical sections influence scheduler latency and how to minimize jitter to ensure your hard real-time tasks meet their deadlines.

The Conflict: ISRs vs. The Scheduler

In an RTOS, the scheduler is responsible for moving the system from one task to the next. However, the scheduler relies on critical sections (code blocks where interrupts are disabled) to protect its internal data structures, such as the "Ready List." When a hardware interrupt triggers, the CPU stops the scheduler to execute an Interrupt Service Routine (ISR). If your ISRs are poorly managed or nested excessively, they effectively "pause" the scheduler, leading to scheduler latency—the time delay between an event occurring and the kernel successfully context-switching to the corresponding task.

Understanding Jitter and Nesting

Jitter refers to the variation in the time it takes for a task to begin executing after it becomes ready. When interrupts are allowed to nest (higher priority interrupts preempting lower priority ones), the scheduler can be held off for a cumulative duration that exceeds your worst-case execution time budget.

Consider this scenario:

void ISR_Handler() {
    // 1. Critical section starts: Scheduler is locked
    OS_EnterCritical(); 
    
    // 2. If this ISR takes too long, or is preempted by a higher priority 
    //    interrupt that also locks the kernel, the scheduler is blocked.
    Process_High_Priority_Event();
    
    OS_ExitCritical();
    // 3. Scheduler is now free to run
}

If Process_High_Priority_Event() contains heavy logic or waits for a slow peripheral, the scheduler remains blocked. If a task becomes "ready" during this window, it cannot run until the ISR exits.

Minimizing Latency

To maintain determinism:

1. Minimize Code in Critical Sections: Keep the OS_EnterCritical() and OS_ExitCritical() blocks as short as possible. Only protect the specific shared variable or kernel object being accessed.
2. Limit Nesting Depth: Evaluate if your hardware architecture requires deep nesting. Excessive nesting makes it nearly impossible to calculate a deterministic "worst-case" latency.
3. Defer Processing: Use the "Deferred Interrupt Processing" pattern we discussed earlier, moving heavy logic from the ISR to a high-priority task, allowing the scheduler to regain control sooner.

Key Takeaway: To ensure predictable timing, keep ISRs short and limit the duration of kernel-disabling critical sections to prevent cumulative scheduler latency that leads to execution jitter.