RTOS concepts — task, scheduler, preemption, context switch: Exercises

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

Do quantities baar baar aati hain, toh chalo inhe shuru hone se pehle plain words mein ek baar phir se state kar lete hain.

Level 1 — Recognition

Recall Solution 1.1

(a) Blocked — woh ek event/resource ka wait kar raha hai aur run karne ke eligible nahi hai. (b) Running — ek core pe sirf ek task hi yahan ho sakta hai. (c) Ready — run karne mein capable hai, bas CPU ki baari ka wait kar raha hai. (d) Suspended — purpose se park kiya gaya hai, kisi event ki wajah se nahi.

Kyun: states is baat se distinguish hoti hain ki task kyun nahi run kar raha — CPU ka wait (Ready) vs event ka wait (Blocked) vs deliberately park kiya gaya (Suspended).

Recall Solution 1.2

Jhooth. PC sirf kahaan tak code tha; woh data jis par kaam ho raha tha general registers (r0–r12) aur status flags mein rehta hai, saath mein stack pointer (SP) ke zariye private stack mein. Unhe kho dena matlab task garbage compute karte hue resume karega. Ek switch poora register set + SP save karta hai, jo task ke TCB (Task Control Block) mein anchored hota hai. Dekho Stack memory and TCB.

Level 2 — Application

Recall Solution 2.1

Kya karein: overhead model mein plug in karo. $η = T_{cs} \cdot f_{t i c k} = (3 \times 1 0^{- 6} s) (500 Hz) = 1.5 \times 1 0^{- 3} = 0.15%.$ Kyun: 1 second mein 500 ticks hote hain; har ek $3 μ s$ waste karta hai, toh $500 \times 3 μ s = 1500 μ s = 1.5 ms$ lost out of $1000 ms$ , yaani $0.15%$ . Sasta — ek healthy design.

Recall Solution 2.2

Kya karein: response-time bound use karo. $T_{r es p} \leq T_{i sr} + T_{cs} = 4 μ s + 3 μ s = 7 μ s .$ Kyun: highest priority hone ki wajah se, koi cheez ise delay nahi kar sakti siwaaye (a) triggering ISR ke khatam hone ke aur (b) exactly ek context switch ke. Lower tasks top task ko block nahi kar sakte. Yeh Rate Monotonic Scheduling ke peeche ka seed idea hai.

Recall Solution 2.3

$1 kHz$ pe: $η = (5 \times 1 0^{- 6}) (1000) = 0.005 = 0.5%$ . $10 kHz$ pe: $η = (5 \times 1 0^{- 6}) (10000) = 0.05 = 5%$ . Verdict: samajhdari nahi. Tick sirf time-based delays drive karta hai; event-driven preemption already interrupts ke zariye instant hai. Tick ko 10× badhane se wasted CPU 10× badh gaya bina kisi responsiveness gain ke. Dekho Interrupts and ISR latency.

Level 3 — Analysis

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

Recall Solution 3.1

$[0, 2)$ ms: A Running; B exist nahi karta / Ready nahi hai.
$t = 2$ pe: B Ready ho jaata hai aur A se zyada rank hai → preemption → context switch → B CPU le leta hai.
$[2, 5)$ ms: B Running; A Ready (run karne mein capable, lekin outranked — Blocked nahi; woh kabhi kisi event ka wait nahi kar raha tha).
$t = 5$ pe: B queue pe block ho jaata hai → B Blocked → A ab highest-priority Ready task hai → switch back → A Running.
$[5, \infty)$ ms: A Running; B Blocked.

$t = 2$ step kyun matter karta hai: preemptive rule B ko immediately run karne par force karta hai, A ke khatam hone ka wait nahi karta. Preemption ke bina (cooperative scheduling), B tab tak wait karta jab tak A voluntarily yield nahi karta — possibly ek deadline miss karte hue.

Recall Solution 3.2

Koi preemption nahi. Preemption strictly priority-driven hai — yeh sirf tab hota hai jab ek higher-priority task Ready ho jaata hai. Equal-priority tasks time-slicing (round-robin) ke zariye share karte hain: har tick boundary pe scheduler agле equal-priority Ready task pe rotate karta hai. Toh Y ko CPU agле tick pe milega, jis pal woh Ready hua us pal nahi. Kyun distinction: preemption "urgency" ka jawab deta hai; round-robin "fairness" ka jawab deta hai. Yeh alag-alag sawaal hain.

Level 4 — Synthesis

Recall Solution 4.1

Priorities (higher number = zyada urgent): Motor = 3, Sensor = 2, WiFi = 1.

Motor (prio 3): interrupt se driven (encoder pulse). Response bound $T_{r es p} \leq T_{i sr} + T_{cs}$ — typical $μ s$ -scale switches ke liye $1 ms$ se kaafi kam. Yeh highest priority hai toh kuch ise block nahi kar sakta.
Sensor (prio 2): $5 ms$ ADC wait ke dauran block karna zaroori hai (e.g. xQueueReceive / ek semaphore jo ADC-done ISR deta hai). Ek busy-wait while(!ready); ise Running rakhega, WiFi se $5 ms$ chura lega aur CPU waste karega. Blocking CPU release karta hai taaki WiFi meanwhile run kar sake.
WiFi (prio 1): sabse kam — sirf gaps mein run karta hai. Ek background task ko exactly yahi karna chahiye.

Yeh ordering kyun: hard-deadline, event-driven kaam ko top priority milti hai taaki preemption uski turant seva kare; slow poll block karta hai taaki woh kabhi core hog na kare; housekeeping idle time soakhta hai. Blocking primitives ke liye dekho Semaphores and Queues.

Recall Solution 4.2

Khatraa: priority inversion. Agar low-priority WiFi mutex hold kar raha hai jab Sensor (higher) ko chahiye, toh Sensor WiFi ka wait karte hue stuck ho jaata hai. Aur bura, agar Motor task mutex ko kabhi touch nahi karta lekin ek medium task WiFi ko preempt karta rehta hai, toh WiFi finish nahi kar sakta aur use release nahi kar sakta — toh Sensor indirectly ek lower-priority task se block ho jaata hai. Fix: priority inheritance — WiFi temporarily Sensor ki priority inherit karta hai jab tak mutex hold kare. Poora treatment Priority Inversion and Mutexes mein.

Level 5 — Mastery

Recall Solution 5.1

Kya karein: overhead model switches per second count karta hai, chahe unka cause kuch bhi ho. Total switches per second $= f_{t i c k} + f_{e v e n t} = 1000 + 3000 = 4000$ . $η = T_{cs} \cdot (f_{t i c k} + f_{e v e n t}) = (2 \times 1 0^{- 6}) (4000) = 8 \times 1 0^{- 3} = 0.8%.$ Verdict: healthy — $5%$ se kaafi kam. Kyun sum: $η = T_{cs} \cdot f_{t i c k}$ generalise hota hai $T_{cs} \cdot (total switch rate)$ mein; ticks aur events dono switches trigger karte hain, toh unki rates add karo.

Recall Solution 5.2

Zero-tick limit: $f_{t i c k} = 0$ aur koi events nahi hone par, $η = T_{cs} \cdot 0 = 0$ — koi switching nahi, koi waste nahi. Tickless idle ka exactly yahi point hai: jab kuch scheduled nahi hota tab periodic tick band karo, power bachao. Maximum meaningful $η$ : $η = 1$ (100%). Yeh tab hota hai jab switch rate $f = 1/ T_{cs}$ tak pahunch jaati hai — CPU har second switching mein spend karta hai aur zero real kaam hota hai. Isse aage model toot jaata hai (tum isse zyada baar switch nahi kar sakte jitna ek switch laita hai). Physically, $η \to 1$ total collapse hai: pure overhead, koi throughput nahi.

Recall Solution 5.3

$η = T_{cs} \cdot f_{t i c k}$ origin se guzarne wali ek straight line hai jiska slope $T_{cs}$ hai — overhead tick rate ke saath linearly badhti hai. Koi "free smoothness" nahi hai: tick double karo toh waste double ho jaata hai. $5%$ crossing $T_{cs} = 5 μ s$ ke saath: $0.05 = (5 \times 1 0^{- 6}) f_{t i c k} \Rightarrow f_{t i c k} = \frac{0.05}{5 \times 1 0 ^{- 6}} = 10000 Hz = 10 kHz .$ Toh $10 kHz$ pe tum smell line hit karte ho; isse kaafi neeche raho. Yahi wajah hai ki real systems tick ko $100$ – $1000 Hz$ pe rakhte hain aur fast tick ki jagah event-driven blocking par rely karte hain.

Recall pass

CPU switching mein jaane wala formula kaunsa hai, aur

T_{cs}

ki units kya honi chahiye?

η = T_{cs} \cdot f_{t i c k}

;

T_{cs}

seconds mein hona chahiye taaki product dimensionless ho.

Ek task out-prioritised hai lekin kisi event ka wait nahi kar raha — kya state hai?

Ready (Blocked nahi).

Kya equal-priority tasks ek doosre ko preempt karte hain?

Nahi — woh tick boundaries pe round-robin time-slicing ke zariye share karte hain.

Kis switch rate par

η

100% tak pahunchta hai?

f = 1/ T_{cs}

— CPU sirf switch karta rehta hai, kuch nahi.

Tick "smoothness" ke liye kyun nahi badhate?

η

f_{t i c k}

ke saath linearly badhti hai; responsiveness event-driven preemption se aati hai, tick rate se nahi.