real-time scheduling

Some computing has a stopwatch attached: an airbag controller that decides too late has failed even if its answer is correct; a video player that decodes a frame a moment late just shows a tiny stutter. Real-time scheduling is about meeting deadlines, not just finishing eventually — its goal is correct timing, where the right result at the wrong time can be as bad as a wrong result.

The key split is between hard and soft real time. In a hard real-time system, missing a deadline is a failure — the brakes must release in time, period — so the scheduler must guarantee that every task completes by its deadline, which usually requires knowing task timings in advance and admitting only a schedulable set. In a soft real-time system, deadlines are important but an occasional miss is tolerable and merely degrades quality (a dropped audio sample, a late frame). Real-time scheduling typically uses priorities tied to timing requirements, and demands a small, bounded dispatch latency so a newly ready urgent task can preempt promptly.

Why it matters and a pitfall: ordinary fairness-oriented schedulers are wrong here, because fairness is not the goal — predictability is. Classic real-time algorithms include rate-monotonic (fixed priorities by how often a task repeats) and earliest-deadline-first (dynamic priorities by which deadline is nearest). A notorious danger in this setting is priority inversion: a high-priority task gets blocked waiting for a resource held by a low-priority task, which can cause a deadline miss; the standard fix is priority inheritance, where the resource holder temporarily borrows the waiter's high priority.