Foundations — Real-time constraints — hard and soft deadlines

This is the "unpack the toolbox" page for Real-time constraints — hard and soft deadlines. The parent note throws a lot of letters at you — $r_i$, $D_i$, $R_i$, $C_i$, $T_i$, $n$, $U$, $\lceil \cdot \rceil$, $\sum$. Here we earn each one, in order, before it is ever used in a formula.

Step 0 — What is a "task" and a "job"?

Before any symbol, we need the thing the symbols describe.

Picture a factory worker (the task) who does the same chore many times a day (each chore is a job). We label tasks with a subscript $i$: task 1, task 2, task 3 — written ${\text{task}}_i$. The subscript is just a name tag so we can talk about "the $i$-th task" without drawing a picture of each one.

Step 1 — The timeline: when things happen

Everything in real-time lives on a single horizontal time axis, seconds increasing to the right. Three moments matter for one job.

Why three separate ideas? Because "when work arrives", "when it's due", and "how long it actually took" are genuinely different questions, and a deadline is a statement relating all three.

Relative vs absolute deadline

The parent writes $d_i=r_i+D_i$. Read this as a picture, not algebra:

Step 2 — How long does the work take? WCET $C_i$

A job needs some amount of CPU time to finish. But that amount varies run to run — a cache miss, a longer input, a branch taken — so a single number won't do. We must pick which number.

Note $C_i$ is a duration (seconds of CPU), just like $R_i$ and $D_i$. Keeping these three "seconds" quantities straight is half the battle.

Step 3 — Repeating work: period $T_i$

Many real-time tasks are periodic — they release a fresh job every fixed interval. The spacing is the period.

The difference between periodic tasks and event-triggered ones is covered in Periodic vs Aperiodic Tasks. For now hold the picture: a metronome ticking every $T_i$ seconds, and each tick a job of length up to $C_i$ appears.

Step 4 — The share of the CPU: utilisation $U_i$ and the sum $\sum$

Now we can ask the money question: how much of the processor does a task eat?

In one period of length $T_i$, the task needs (worst case) $C_i$ seconds of CPU. The fraction of that period spent on the task is:

Why a ratio? Because "2 ms of work" means nothing without knowing how often it recurs. 2 ms every 10 ms is light; 2 ms every 3 ms is heavy. The ratio $C_i/T_i$ captures ongoing demand, which is exactly what a shared CPU cares about.

The summation symbol $\sum$

To combine several tasks we add their shares. The parent writes $U={\sum }_{i=1}^n\frac{C_i}{T_i}$, where $n$ is the task count from Step 0.

Step 5 — The ceiling symbol $\lceil x\rceil$

The parent's exact test uses $\lceil \frac{R_i}{T_j}\rceil$. That funny bracket is the last symbol to unlock.

The full preemption count logic belongs to RTOS scheduler design and Rate-Monotonic Scheduling; here we only needed to read the symbol.

How the foundations feed the topic

Read top to bottom: raw ideas (task, WCET, period, symbols) combine into the deadline test and the utilisation sum, which together power the classification of deadlines and the schedulability proofs the parent note builds.

Equipment checklist

Cover the right side and answer before revealing.