Q22Real Time Systems

A Real-Time System is mathematically anchored by Periodic tasks (e.g., executing every 10ms). However, the real world throws chaotic Aperiodic tasks at the system (e.g., an emergency shutdown button pressed at a random microsecond). If the OS gives the aperiodic task maximum priority, it will violently steal CPU time and crash the periodic tasks. If it gives it lowest priority, the emergency button response will be catastrophically delayed. We must mathematically create a bounded, safe execution channel.

Aperiodic tasks are simply given the absolute lowest priority in the system. They only execute when all periodic tasks are asleep. The Catastrophe: If the CPU is running at 90% utilization, the aperiodic task might mathematically wait for 5 seconds to get CPU time. This is completely unacceptable for an emergency interrupt.

The OS mathematically creates a fake periodic task called the "Polling Server" (PS).

• The Architecture: The PS is given a rigid period (e.g., $T_{ps}=10ms$) and a strict CPU budget (e.g., $C_{ps}=2ms$). The RMS scheduler mathematically treats it like any other periodic task, guaranteeing system stability.
• The Execution: When the PS wakes up, it checks an aperiodic queue. If an aperiodic task is waiting, it violently executes it using its 2ms budget.
• The Demerit: If the PS wakes up and the queue is empty, it mathematically throws away its 2ms budget and goes back to sleep. If an emergency aperiodic task arrives 1 microsecond later, it must catastrophically wait an entire 10ms cycle for the PS to wake up again.

The Deferrable Server (DS) solves the catastrophic waste of the Polling Server.

• The Architecture: Like the PS, it is given a period and a budget (e.g., 2ms every 10ms).
• The Genius (Bandwidth Preservation): If the DS wakes up and the queue is empty, it DOES NOT throw away its budget. It mathematically retains its 2ms budget for the entire duration of its 10ms period.
• The Execution: If an emergency aperiodic task arrives at the 5ms mark, the DS instantly violently triggers, uses its retained 2ms budget, and executes the task immediately with zero latency.
• The Math: This drastically slashes the response time for aperiodic tasks compared to the Polling Server, while still mathematically guaranteeing that the aperiodic tasks can never consume more than 20% (2ms/10ms) of the CPU, perfectly protecting the periodic deadlines.

Beyond the Deferrable Server — Sporadic Servers: Even the Deferrable Server has a subtle schedulability weakness: because it can replenish its full budget at the start of every period, it can in the worst case execute two full budgets back-to-back near a period boundary (once just before the period ends and again immediately as the new period begins), an effect that complicates exact RMS schedulability analysis for the rest of the periodic task set. The Sporadic Server refines this further by tying the budget replenishment time to the moment aperiodic execution actually begins, rather than blindly refilling at the start of every fixed period, preserving the responsiveness benefits of the Deferrable Server while restoring the clean mathematical schedulability guarantees needed for formal Hard Real-Time certification. This progression — from naive Background processing, to bandwidth-limited Polling, to the improved Deferrable Server, to the fully schedulability-safe Sporadic Server — illustrates how real-time scheduling theory incrementally refines a solution to satisfy both responsiveness and provable safety simultaneously, a recurring pattern across many areas of real-time systems design.