Worked examples — RTOS concepts — task, scheduler, preemption, context switch

---

The scenario matrix

Think of a scheduling situation as a set of inputs: how many tasks, what priorities, who is Ready, and how expensive a switch is. Each "cell" below is a distinct class of behaviour the scheduler can show. We cover them all.

Cell	Case class	What is special about it	Example
C1	Higher-priority arrival	preemption fires mid-execution	Ex 1
C2	Equal priority (tie)	no preemption — round-robin instead	Ex 2
C3	Lower-priority arrival	preemption does not fire	Ex 3
C4	Degenerate: nothing Ready	scheduler must run the idle task	Ex 4
C5	Overhead — normal regime	$\eta =T_{cs}{f}_{tick}$ small	Ex 5
C6	Overhead — limiting regime	$\eta \to 1$, system chokes	Ex 6
C7	Response time bound	highest-priority latency $T_{isr}+T_{cs}$	Ex 7
C8	Real-world word problem	motor + WiFi + sensor, does it meet deadlines?	Ex 8
C9	Exam twist	busy-wait vs block changes the answer	Ex 9

---

Example 1 — Higher-priority arrival (cell C1)

Forecast: guess before reading — does B wait for A to finish, or does A get paused instantly?

1. At $t=2$ ms the ISR marks B as Ready. Why this step? Readiness is the entry ticket — only now does B even compete for the CPU.
2. Scheduler re-evaluates: highest-priority Ready task? B has priority 3 > A's 1. Why this step? The fixed-priority preemptive rule says always run the highest-priority Ready task — it must re-check the instant anything becomes Ready.
3. Preempt A → context switch → B runs. A's registers are saved to A's stack, its SP stored in A's TCB; B's SP loaded, its registers restored. Why this step? Preemption means A is paused without its cooperation; the TCB holds the handle to A's frozen state.
4. When B blocks (waits for next event), A resumes. Why this step? A is again the highest-priority Ready task, so the scheduler restores it exactly where it was frozen at step 3.

Verify: priority comparison $3>1$ ⇒ preempt. Consistent with the rule "higher priority Ready ⇒ run now." B never waits for A's loop to finish. ✓

---

Example 2 — Equal priority, a tie (cell C2)

Forecast: same priority — does the newer task shove out the older one?

1. Compare priorities: 2 vs 2 — equal. Why this step? Preemption is strictly priority-driven: it requires the newcomer to be higher, not equal.
2. No preemption occurs. Why this step? An equal-priority task has no claim to interrupt; forcing a switch here would just burn overhead for no urgency gain.
3. At the next tick, the scheduler time-slices: C is switched out, D runs. Why this step? Equal-priority tasks share the CPU by round-robin at tick boundaries — fair turns, not preemption.
4. On the tick after that, D→C again, and so on. Why this step? Round-robin cycles the equal-priority Ready set one slice each.

Verify: switches happen only at tick boundaries, spaced by one tick period. With a $1\text{kHz}$ tick that is one switch every $1\text{ms}$ between C and D — not instantaneous like C1. ✓ (This is the "equal priority can preempt" mistake, corrected.)

---

Example 3 — Lower-priority arrival (cell C3)

Forecast: a new task became Ready — must the scheduler switch?

1. Compare: F's 1 vs E's 4. F is lower. Why this step? Same rule, opposite outcome — the comparison decides everything.
2. E keeps the CPU; F goes to the Ready queue and waits. Why this step? Nothing higher-priority is Ready, so there is no reason to switch. A switch here would be pure waste.
3. F runs only when E blocks or finishes. Why this step? F becomes the highest-priority Ready task only after E leaves the Running state.

Verify: $1<4$ ⇒ no preemption. Zero context switches caused by F's arrival. ✓

---

Example 4 — Degenerate: nothing Ready (cell C4)

Forecast: can the CPU run nothing? What fills the gap?

1. Scheduler searches for the highest-priority Ready task — finds none. Why this step? The Ready set is empty, but a CPU must always execute some instruction stream.
2. The RTOS runs the built-in idle task (lowest priority, always Ready). Why this step? It is a guaranteed fallback so the scheduler's "pick highest Ready" never fails; the idle task typically issues a WFI (wait-for-interrupt) to save power.
3. The next event (ISR) unblocks a real task → scheduler preempts idle instantly. Why this step? Idle is lowest priority, so any Ready task outranks it — collapsing back to cell C1.

Verify: Ready set $=\varnothing$ ⇒ idle runs; idle priority is below every task, so it is preempted by the first arrival. No deadlock, no crash. ✓

---

Example 5 — Overhead, normal regime (cell C5)

Forecast: guess the percentage before computing.

1. Use the overhead model $\eta =T_{cs}\cdot f_{tick}$. Why this step? In one second there are $f_{tick}$ ticks; each may force one switch costing $T_{cs}$ seconds, so wasted time $=f_{tick}{T}_{cs}$ out of $1\text{s}$.
2. Substitute: $\eta =(2\times 10^{-6})(1000)=0.002$. Why this step? Convert $2\mu s=2\times 10^{-6}\text{s}$ so units cancel: $\text{s}\times \text{Hz}=\text{s}\times {\text{s}}^{-1}$ = dimensionless.
3. As a percent: $0.002=0.2\%$. Why this step? Multiply by 100 to express the pure fraction as a percentage.

Verify: dimensionless result in $[0,1]$ — sane. $0.2\%$ overhead is negligible. ✓

---

Example 6 — Overhead, limiting regime (cell C6)

Forecast: does a faster tick make the system more real-time? Guess the two percentages.

1. At $100\text{kHz}$: $\eta =(2\times 10^{-6})(100000)=0.20=20\%$. Why this step? Same model — but now switching alone eats a fifth of the CPU before any real work.
2. At $500\text{kHz}$: $\eta =(2\times 10^{-6})(500000)=1.0=100\%$. Why this step? This is the limiting case: the product $T_{cs}{f}_{tick}\to 1$, meaning the CPU spends all its time switching and none running tasks — total collapse.
3. Interpret the limit. For $\eta <1$ we need $f_{tick}<1/T_{cs}=500\text{kHz}$. Why this step? Beyond this the model gives $\eta >1$, which is physically impossible — it signals the CPU can't even keep up with its own switching. Keep tick modest ($100$–$1000\text{Hz}$).

Verify: at $f_{tick}=1/T_{cs}$, $\eta =T_{cs}\cdot (1/T_{cs})=1$ exactly. Faster tick ⇒ worse, not better — refutes the "higher tick = more real-time" myth. ✓ See Rate Monotonic Scheduling for why event-driven preemption already gives instant response without a fast tick.

---

Example 7 — Response-time bound (cell C7)

Forecast: can anything else delay the highest-priority task?

1. Write the bound $T_{resp}\le T_{isr}+T_{cs}$. Why this step? Because G is highest priority, only two things can delay it: finishing the triggering ISR ($T_{isr}$) and one switch into G ($T_{cs}$). No task can block the top task (ignoring priority inversion).
2. Substitute: $T_{resp}\le 1.5\mu s+2\mu s=3.5\mu s$. Why this step? Add the two independent delays; both are pure time so they sum directly.

Verify: $3.5\mu s$ is far below a typical $1\text{ms}$ deadline ⇒ G comfortably meets it. Units: $\mu s+\mu s=\mu s$. ✓ Details of $T_{isr}$ in Interrupts and ISR latency.

---

Example 8 — Real-world word problem (cell C8)

Forecast: WiFi is busy — will the motor be stuck behind it?

1. Encoder ISR fires → Motor becomes Ready. Why this step? Only a Ready task competes; the ISR is the trigger.
2. Motor priority 5 > running WiFi priority 1 ⇒ preempt WiFi (cell C1 pattern). Why this step? WiFi's long loop does not protect it — preemption is forcible.
3. Response time $T_{resp}\le T_{isr}+T_{cs}=1\mu s+2\mu s=3\mu s$. Why this step? Motor is the highest priority, so use the C7 bound.
4. Compare to deadline: $3\mu s\ll 1000\mu s$. Why this step? Convert the $1\text{ms}$ deadline to $1000\mu s$ so both are in $\mu s$; the margin is huge.

Verify: $3\mu s<1000\mu s$ ⇒ deadline met with ~333× margin. WiFi's length is irrelevant because preemption is instant. ✓ (If WiFi held a mutex the Motor needed, we'd hit priority inversion — a different chapter.)

---

Example 9 — Exam twist: busy-wait vs block (cell C9)

Forecast: in which design does B get to run during the 5 ms wait?

1. Design X — busy-wait. A stays Running the whole $5\text{ms}$, spinning. Why this step? A never leaves the Running state, so it remains the highest-priority Ready task and hogs the CPU.
2. B's useful $4\text{ms}$ of work is starved. Wasted useful capacity $=4\text{ms}$. Why this step? B is lower priority and A never yields, so B simply cannot run — that work is lost from the 5 ms window.
3. Design Y — block. xQueueReceive moves A to Blocked. Why this step? A blocking call releases the CPU by leaving the Running state.
4. Scheduler runs B (now highest-priority Ready) for its $4\text{ms}$; CPU can idle only the remaining $1\text{ms}$. Why this step? With A Blocked, B is the top Ready task; useful work fills the gap. Idle waste $=5-4=1\text{ms}$.

Verify: Design X wastes $4\text{ms}$ of possible useful work; Design Y wastes only $1\text{ms}$ (unavoidable, since B only has 4 ms of work). Blocking recovers $4-1=3\text{ms}$. ✓

---

Recall

Recall Which arrival cases fire preemption?

Only a strictly higher-priority newcomer (C1). Equal (C2) ⇒ round-robin at ticks. Lower (C3) ⇒ nothing happens. Higher priority arrives while lower runs — result? ::: Immediate preemption + context switch. Two equal-priority tasks both Ready — how do they share? ::: Round-robin time-slicing at tick boundaries, not preemption. Every task Blocked — what runs? ::: The idle task (lowest priority, always Ready).

Recall The overhead limit

At what tick frequency does switching consume 100% of the CPU? ::: $f_{tick}=1/T_{cs}$, since $\eta =T_{cs}{f}_{tick}=1$ there. Worst-case response of the highest-priority task? ::: $T_{resp}\le T_{isr}+T_{cs}$.