rate-monotonic scheduling

Suppose you have several chores that each repeat on their own clock — water the plants every hour, check the mail every day, pay rent every month. A sensible rule is to give the most frequent chore the highest priority, because it has the least slack before it must be done again. Rate-monotonic scheduling applies exactly this rule to periodic real-time tasks: the shorter a task's period (the more often it repeats), the higher its fixed priority.

How it works: each task is periodic, arriving every P time units and needing C units of CPU each time, with its deadline at the end of its period. Rate-monotonic assigns priorities once, statically, by rate — a task that repeats every 20 ms outranks one that repeats every 50 ms — and then runs them by preemptive fixed-priority scheduling. It is the optimal static-priority scheme: if any fixed-priority assignment can meet all deadlines, the rate-monotonic one can too. There is even a simple sufficient test: a set of n tasks is schedulable if their total CPU utilization stays under n times (2^(1/n) - 1), a bound that approaches about 0.69 (the natural log of 2) for many tasks.

Why it matters and its limits: rate-monotonic is the classic, well-understood choice for hard real-time systems with periodic tasks, and its static priorities make it simple and predictable to analyze. The honest caveats: it can fail to use the CPU fully — its guaranteed utilization bound is only about 69 percent, so a task set above that may still miss deadlines even though the CPU is not full. It also assumes independent, periodic tasks with deadlines equal to periods; reality (shared resources, sporadic tasks) needs extensions like priority inheritance.