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

5.5.9 · D3 · Coding › Embedded Systems & Real-Time Software › RTOS concepts — task, scheduler, preemption, context switch

The scenario matrix

Ek scheduling situation ko inputs ke ek set ki tarah socho: kitne tasks hain, kya priorities hain, kaun Ready hai, aur ek switch kitna expensive hai. Neeche har "cell" ek alag class of behaviour hai jo scheduler dikhaa sakta hai. Hum inhe sab cover karte hain.

Cell	Case class	Isme kya special hai	Example
C1	Higher-priority arrival	preemption mid-execution fire hoti hai	Ex 1
C2	Equal priority (tie)	koi preemption nahi — round-robin hota hai	Ex 2
C3	Lower-priority arrival	preemption fire nahi hoti	Ex 3
C4	Degenerate: kuch bhi Ready nahi	scheduler ko idle task run karna padta hai	Ex 4
C5	Overhead — normal regime	$η = T_{cs} f_{t i c k}$ chhota hai	Ex 5
C6	Overhead — limiting regime	$η \to 1$ , system choke karta hai	Ex 6
C7	Response time bound	highest-priority latency $T_{i sr} + T_{cs}$	Ex 7
C8	Real-world word problem	motor + WiFi + sensor, kya deadlines meet honge?	Ex 8
C9	Exam twist	busy-wait vs block answer badal deta hai	Ex 9

Figure — RTOS concepts — task, scheduler, preemption, context switch

Example 1 — Higher-priority arrival (cell C1)

Forecast: padhne se pehle andaza lagao — kya B A ke khatam hone ka wait karega, ya A ko immediately pause kar diya jaayega?

$t = 2$ ms par ISR B ko Ready mark karta hai. Yeh step kyun? Readiness entry ticket hai — sirf ab B compete karne ke liye eligible bana hai.
Scheduler re-evaluate karta hai: highest-priority Ready task? B ki priority 3 > A ki 1. Yeh step kyun? Fixed-priority preemptive rule kehta hai hamesha highest-priority Ready task run karo — jaise hi kuch bhi Ready hota hai, usi pal dobara check karna zaroori hai.
A ko preempt karo → context switch → B run karta hai. A ke registers A ki stack mein save hote hain, uska SP A ki TCB mein store hota hai; B ka SP load hota hai, uske registers restore hote hain. Yeh step kyun? Preemption ka matlab hai A ko uski marzi ke bina pause kiya jaata hai; TCB A ki frozen state ka handle hold karta hai.
Jab B block karta hai (agli event ka wait karta hai), A resume karta hai. Yeh step kyun? A phir se highest-priority Ready task ban jaata hai, toh scheduler usse exactly wahan restore karta hai jahan woh step 3 mein freeze hua tha.

Verify: priority comparison $3 > 1$ ⇒ preempt. Rule ke saath consistent — "higher priority Ready ⇒ abhi run karo." B kabhi A ki loop khatam hone ka wait nahi karta. ✓

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

Forecast: same priority — kya newer task purane wale ko bahar dhakkelega?

Priorities compare karo: 2 vs 2 — equal hain. Yeh step kyun? Preemption strictly priority-driven hai: newcomer ka higher hona zaroori hai, equal nahi.
Koi preemption nahi hoti. Yeh step kyun? Equal-priority task ka interrupt karne ka koi claim nahi; yahan forcibly switch karna sirf overhead burn karna hoga bina kisi urgency gain ke.
Agli tick par scheduler time-slice karta hai: C switch out hota hai, D run karta hai. Yeh step kyun? Equal-priority tasks CPU share karte hain round-robin ke zariye tick boundaries par — fair turns, na ki preemption.
Uske baad wali tick par D→C phir, aur aise chalata rehta hai. Yeh step kyun? Round-robin equal-priority Ready set ko ek-ek slice rotate karta hai.

Verify: switches sirf tick boundaries par hote hain, ek tick period ke gap se. $1 kHz$ tick ke saath C aur D ke beech har $1 ms$ mein ek switch hoga — C1 ki tarah instantaneous nahi. ✓ (Yeh "equal priority preempt kar sakta hai" wali galti hai, correct ki gayi.)

Example 3 — Lower-priority arrival (cell C3)

Forecast: ek naya task Ready ho gaya — kya scheduler ko switch karna hi chahiye?

Compare karo: F ki 1 vs E ki 4. F lower hai. Yeh step kyun? Wahi rule, ulta outcome — comparison hi sab decide karta hai.
E CPU rakhta hai; F Ready queue mein jaata hai aur wait karta hai. Yeh step kyun? Koi higher-priority task Ready nahi hai, isliye switch karne ki koi wajah nahi. Yahan switch karna pure waste hoga.
F sirf tab run karta hai jab E block kare ya finish kare. Yeh step kyun? F highest-priority Ready task sirf tab banta hai jab E Running state chhod deta hai.

Verify: $1 < 4$ ⇒ koi preemption nahi. F ki arrival se zero context switches. ✓

Example 4 — Degenerate: kuch bhi Ready nahi (cell C4)

Forecast: kya CPU kuch bhi run nahi kar sakta? Gap kya fill karta hai?

Scheduler highest-priority Ready task dhundta hai — kuch nahi milta. Yeh step kyun? Ready set empty hai, lekin ek CPU ko hamesha koi na koi instruction stream execute karna hi hota hai.
RTOS built-in idle task run karta hai (lowest priority, hamesha Ready). Yeh step kyun? Yeh ek guaranteed fallback hai taaki scheduler ka "pick highest Ready" kabhi fail na ho; idle task typically WFI (wait-for-interrupt) issue karta hai power save karne ke liye.
Agli event (ISR) ek real task ko unblock karta hai → scheduler idle ko immediately preempt karta hai. Yeh step kyun? Idle lowest priority hai, isliye koi bhi Ready task use outrank karta hai — yeh cell C1 par wapas collapse kar jaata hai.

Verify: Ready set $= \emptyset$ ⇒ idle run karta hai; idle ki priority har task se neeche hai, isliye pehli arrival par hi preempt ho jaata hai. Koi deadlock nahi, koi crash nahi. ✓

Example 5 — Overhead, normal regime (cell C5)

Forecast: compute karne se pehle percentage guess karo.

Overhead model use karo $η = T_{cs} \cdot f_{t i c k}$ . Yeh step kyun? Ek second mein $f_{t i c k}$ ticks hote hain; har ek mein ek switch ho sakta hai jo $T_{cs}$ seconds leta hai, toh wasted time $= f_{t i c k} T_{cs}$ out of $1 s$ .
Substitute karo: $η = (2 \times 1 0^{- 6}) (1000) = 0.002$ . Yeh step kyun? $2 μ s = 2 \times 1 0^{- 6} s$ convert karo taaki units cancel ho jaayein: $s \times Hz = s \times s^{- 1}$ = dimensionless.
Percent mein: $0.002 = 0.2%$ . Yeh step kyun? Pure fraction ko percentage ke roop mein express karne ke liye 100 se multiply karo.

Verify: dimensionless result $[0, 1]$ mein — sane hai. $0.2%$ overhead negligible hai. ✓

Example 6 — Overhead, limiting regime (cell C6)

Forecast: kya faster tick system ko zyada real-time banata hai? Dono percentages guess karo.

$100 kHz$ par: $η = (2 \times 1 0^{- 6}) (100000) = 0.20 = 20%$ . Yeh step kyun? Wahi model — lekin ab sirf switching CPU ka ek-panchaansh kha jaati hai kisi bhi real kaam se pehle.
$500 kHz$ par: $η = (2 \times 1 0^{- 6}) (500000) = 1.0 = 100%$ . Yeh step kyun? Yeh limiting case hai: product $T_{cs} f_{t i c k} \to 1$ , matlab CPU apna saara time switching mein spend karta hai aur tasks run karne mein kuch nahi — complete collapse.
Limit interpret karo. $η < 1$ ke liye hume $f_{t i c k} < 1/ T_{cs} = 500 kHz$ chahiye. Yeh step kyun? Isse aage model $η > 1$ deta hai, jo physically impossible hai — yeh signal hai ki CPU apni khud ki switching bhi nahi sambhal sakta. Tick modest rakho ( $100$ – $1000 Hz$ ).

Verify: $f_{t i c k} = 1/ T_{cs}$ par, $η = T_{cs} \cdot (1/ T_{cs}) = 1$ exactly. Faster tick ⇒ worse, better nahi — "higher tick = more real-time" myth refute hoti hai. ✓ Dekho Rate Monotonic Scheduling yeh jaanne ke liye ki event-driven preemption kaise fast tick ke bina instant response deti hai.

Example 7 — Response-time bound (cell C7)

Forecast: kya koi aur cheez highest-priority task ko delay kar sakti hai?

Bound likhо $T_{r es p} \leq T_{i sr} + T_{cs}$ . Yeh step kyun? G highest priority hai, isliye sirf do cheezein use delay kar sakti hain: triggering ISR finish hona ( $T_{i sr}$ ) aur G mein ek switch ( $T_{cs}$ ). Koi task top task ko block nahi kar sakta (ignoring priority inversion).
Substitute karo: $T_{r es p} \leq 1.5 μ s + 2 μ s = 3.5 μ s$ . Yeh step kyun? Dono independent delays add karo; dono pure time hain isliye directly sum hote hain.

Verify: $3.5 μ s$ ek typical $1 ms$ deadline se kaafi neeche hai ⇒ G aaram se meet karta hai. Units: $μ s + μ s = μ s$ . ✓ $T_{i sr}$ ki details Interrupts and ISR latency mein hain.

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

Forecast: WiFi busy hai — kya motor uske peeche fase rahega?

Encoder ISR fire hoti hai → Motor Ready ban jaata hai. Yeh step kyun? Sirf Ready task compete karta hai; ISR trigger hai.
Motor priority 5 > running WiFi priority 1 ⇒ WiFi preempt hota hai (cell C1 pattern). Yeh step kyun? WiFi ka lamba loop use protect nahi karta — preemption forcible hai.
Response time $T_{r es p} \leq T_{i sr} + T_{cs} = 1 μ s + 2 μ s = 3 μ s$ . Yeh step kyun? Motor highest priority hai, isliye C7 bound use karo.
Deadline se compare karo: $3 μ s ≪ 1000 μ s$ . Yeh step kyun? $1 ms$ deadline ko $1000 μ s$ mein convert karo taaki dono $μ s$ mein hon; margin bahut bada hai.

Verify: $3 μ s < 1000 μ s$ ⇒ deadline ~333× margin ke saath meet hoti hai. WiFi ki length irrelevant hai kyunki preemption instant hai. ✓ (Agar WiFi ne koi mutex hold kiya hota jis Motor ko chahiye tha, toh hum priority inversion mein phans jaate — woh alag chapter hai.)

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

Forecast: kis design mein B ko 5 ms wait ke dauran run karne ka mauka milta hai?

Design X — busy-wait. A poore $5 ms$ Running rehta hai, spinning karta hua. Yeh step kyun? A kabhi Running state nahi chhodata, isliye woh highest-priority Ready task bana rehta hai aur CPU hog karta hai.
B ka useful $4 ms$ ka kaam starve ho jaata hai. Wasted useful capacity $= 4 ms$ . Yeh step kyun? B lower priority hai aur A kabhi yield nahi karta, isliye B simply run nahi kar sakta — woh kaam 5 ms window se lost ho jaata hai.
Design Y — block. xQueueReceive A ko Blocked mein move kar deta hai. Yeh step kyun? Ek blocking call CPU ko release karta hai Running state leave karke.
Scheduler B ko run karta hai (ab highest-priority Ready) uske $4 ms$ ke liye; CPU sirf baaki $1 ms$ idle reh sakta hai. Yeh step kyun? A Blocked hone par B top Ready task hai; useful kaam gap fill karta hai. Idle waste $= 5 - 4 = 1 ms$ .

Verify: Design X $4 ms$ possible useful work waste karta hai; Design Y sirf $1 ms$ waste karta hai (unavoidable, kyunki B ke paas sirf 4 ms ka kaam hai). Blocking $4 - 1 = 3 ms$ recover karta hai. ✓

Recall

Recall Kaun se arrival cases preemption fire karte hain?

Sirf ek strictly higher-priority newcomer (C1). Equal (C2) ⇒ ticks par round-robin. Lower (C3) ⇒ kuch nahi hota. Higher priority lower ke run karte waqt aata hai — result? ::: Immediate preemption + context switch. Do equal-priority tasks dono Ready hain — woh share kaise karte hain? ::: Tick boundaries par round-robin time-slicing, preemption nahi. Har task Blocked — kya run karta hai? ::: Idle task (lowest priority, hamesha Ready).

Recall Overhead limit

Kis tick frequency par switching CPU ka 100% consume karti hai? ::: $f_{t i c k} = 1/ T_{cs}$ , kyunki wahan $η = T_{cs} f_{t i c k} = 1$ hota hai. Highest-priority task ka worst-case response? ::: $T_{r es p} \leq T_{i sr} + T_{cs}$ .