RTOS concepts — task, scheduler, preemption, context switch: Visual walkthrough

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

Hum parent RTOS concepts note ke upar build karte hain lekin assume karte hain ki aap kuch nahi jaante. Har word — register, stack, TCB — use hone se pehle samjhaya jaayega.

Step 0 — "CPU kahan hai" ka matlab kya hai? (woh cheez jo hume save karni hai)

KYA HAI. Kisi task ki state ko save karne se pehle, hume yeh jaanna hoga ki "state" hoti kya hai. Ek CPU ek chhoti si machine hai jo ek hi kaam karti hai: memory se ek number padho, arithmetic karo, wapas likhdo — baar baar. Iske liye woh apne andar kuch chhote scratch boxes rakhta hai jinhein registers kehte hain.

KYUN. Task jo "abhi soch raha hai" woh sab kuch un boxes mein hi hota hai. Agar hum CPU ko freeze karke har register ki photo lete, toh woh photo hi task hai. Uss task ke current instant ke baare mein koi aur cheez nahi hai jisko CPU track kho sakta ho.

PICTURE. Hamare liye teen registers sabse zyada matter karte hain:

Program counter (PC) — ek pointer jo kehta hai "meri next instruction yahan hai." Socho jaise recipe ki ek line par ungli rakhi ho.
Stack pointer (SP) — ek pointer jo is task ke private scratch-paper pile (iska stack) ke top ki taraf point karta hai.
General registers (r0–r12) aur status flags — woh actual numbers jo juggle ho rahe hain.

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

Step 1 — Do tasks, ek CPU, do private stacks

KYA HAI. Hum scene set karte hain. Task A (low priority) aur Task B (high priority) dono ko apna apna stack milta hai — ek private RAM ka tukda jo plates ki stack ki tarah use hota hai: upar ek plate push karo, upar wali plate pop karo.

KYUN. Har task ko apne registers dump karne ki jagah chahiye jise koi doosra task touch na kare. Woh jagah uska apna stack hai. Agar do tasks ek stack share karte, toh A ki photo save karna B ki photo ko overwrite kar deta — instant corruption.

PICTURE. Do alag paper piles. CPU ka akela SP register abhi A ki pile mein point kar raha hai, kyunki A hi Running hai.

$SP ⟶ top of Task A’s stack (A is Running)$

$SP$ — stack pointer, woh ek SP jo CPU physically rakhta hai.
"top of Task A's stack" — jahan A ka next push land hoga.
$(A is Running)$ — ek waqt mein sirf ek task live SP hold kar sakta hai; wahi task Running hai.

Step 2 — Trigger: koi cheez kehti hai "check karo kaun sabse urgent hai"

KYA HAI. Kisi ek instant par ek trigger fire hota hai. Yeh periodic tick ho sakta hai (ek timer interrupt jo, maano, 1000 baar per second fire karta hai) ya koi event jaise ek button ISR jo B ko Ready bana de.

KYUN. Scheduler hamesha nahi chalta — isse CPU waste hota. Yeh sirf tab jaagta hai jab kuch cheez "kaun sabse high-priority Ready task hai?" ka jawab change kar sakti ho. Ek tick ya unblocking event bilkul aisa hi ek moment hai. (Interrupt khud kaise aata hai, iske liye dekho Interrupts and ISR latency.)

PICTURE. Running CPU par bijli girti hai. B, jo pehle Blocked tha, Ready ho jaata hai aur — kyunki B ki priority (3) A ki (1) se zyada hai — scheduler decide karta hai ki switch hona chahiye.

Step 3 — Hardware aadhi photo khud save kar leta hai

KYA HAI. Cortex-M CPU par, jaise hi koi exception (interrupt) shuru hota hai, *hardware khud current stack par aath registers automatically push kar deta hai: r0, r1, r2, r3, r12, LR, PC, xPSR.

KYUN. Yeh aath woh hain jo calling convention ke hisaab se interrupt handler clobber kar sakta hai, toh CPU hamare koi code run hone se pehle, kuch nanoseconds mein, inhe free mein protect kar leta hai. Aadhi photo toh humari jagah le li gayi.

PICTURE. A ki stack par aath plates girti hain; SP neechay slide ho ke unke upar aa jaata hai. Yeh automatic block exception stack frame kehlaata hai.

$hardware auto-push {r 0, r 1, r 2, r 3, r 12, L R, P C, x P S R} \to A’s stack$

Braces mein exactly woh aath registers listed hain jo hardware save karta hai.
Andar $P C$ — yeh sabse crucial hai: yeh record karta hai A kahan interrupt hui thi, taaki A baad mein wahan resume kar sake.
$x P S R$ — status/flags register (kya last result zero tha? negative? carry?), zaroori hai taaki A ki arithmetic ka matlab rehta rahe.

Step 4 — Software doosri aadhi save karta hai (PendSV handler mein)

KYA HAI. CPU ek special handler mein jump karta hai jise PendSV kehte hain. Wahan haara switch code manually baaki registers r4–r11 ko A ki stack par push karta hai.

DO AADHE KYUN? Hardware ne sirf "caller-saved" aath save kiye. r4–r11 "callee-saved" hain — hardware assume karta hai ki koi aur inhe protect karega, toh hume karna padega. Inhe push karo aur A ki photo ab complete hai: har live register A ki stack par hai.

PendSV hi kyun? PendSV ko sabse low interrupt priority par configure kiya jaata hai. Toh yeh sirf tab fire hota hai jab har real, urgent ISR khatam ho chuka ho. Hum hardware service ke beech mein kabhi tasks switch nahi karte — woh ek uljha hua mess hota.

PICTURE. Aath aur plates (r4–r11) A ki pile par girti hain. A ka poora context ab paper par frozen hai.

$context (A) = software push {r 4 - r 11} \cup hardware push {r 0 - r 3, r 12, L R, P C, x P S R}$

Left set — woh aath jo hum code mein push karte hain.
Right set — woh aath jo hardware ne Step 3 mein already push kar diye.
Unka union = saara volatile CPU state. A ke baare mein kuch bhi unsaved nahi raha.

Step 5 — Frozen photo ko ek number se anchor karo: SP → TCB

KYA HAI. Hum A ka final SP lete hain (jo ab A ke complete saved frame ke bilkul upar point kar raha hai) aur ise A ke Task Control Block (TCB) mein likh dete hain.

KYUN. 16 saved plates ki ek stack useless hai agar hum bhool jaayein pile kahan hai. Akela SP value poore frame ka handle hai — ek number jo hume 16 saare registers phir se dhoondne deta hai. TCB woh per-task filing card hai jo RTOS rakhta hai: priority, state, aur yeh saved SP. (Aur zyada Stack memory and TCB mein.)

PICTURE. TCB_A label waala ek chhota index card ek field fill karta hai: saved_SP = 0x2000_0F40 (top plate ki taraf ek pointer arrow).

$TCB_{A} . savedSP \leftarrow SP$

$TCB_{A} . savedSP$ — A ki filing card par woh slot.
$SP$ — live stack pointer, jo ab A ke fully-saved frame par point kar raha hai.
Arrow ka matlab hai "value copy karo": ek number ab hamesha ke liye A ka poora context unlock karta hai.

Step 6 — Scheduler B ko choose karta hai, B ka SP load karta hai

KYA HAI. Scheduler TCBs scan karta hai, highest-priority Ready task dhundhta hai (woh B hai), aur TCB_B.savedSP ko wapas live SP register mein load karta hai.

KYUN. Ab CPU ka SP A ki pile ki jagah B ki pile mein point karta hai. Is instant se, har push/pop B ki memory ko touch karta hai. Humne swap kar diya ki CPU kaun sa "self" pahan raha hai. Scheduler jo rule use karta hai — hamesha highest-priority Ready task — Rate Monotonic Scheduling ki neev hai.

PICTURE. SP arrow A ki pile se uthta hai aur B ki saved pile ke upar land karta hai (B pehle switch out hua tha, toh B ki pile mein pehle se B ki 16 plates saved hain).

$SP \leftarrow TCB_{B} . savedSP$

Hum live SP ko uss number se overwrite karte hain jo humne B ke last baar sone par file kiya tha.
Ek assignment CPU ki identity A se B mein flip kar deta hai.

Step 7 — B ki photo restore karo aur B mein return karo

KYA HAI. Steps 4 aur 3 ka mirror, ulta chala. Haara PendSV code B ki stack se r4–r11 ko pop karta hai. Phir ek special "exception return" hardware ko baaki aath — including B ka PC — pop karaata hai. CPU ki ungli exactly usi instruction par land karti hai jo B run karne wali thi jab ise last baar pause kiya gaya tha.

KYUN. Restore karna un-saving hai. Kyunki B ka PC aur flags bit-for-bit restore hote hain, B aisa chalata rehta hai jaise koi waqt nahi guzra — ise pata bhi nahi chalta ki yeh 2 ms soyi thi. Wahi seamlessness poori baat hai.

PICTURE. Plates B ki pile se wapas registers mein uthti hain; PC ki ungli B ki next line par snap karti hai. B ab Running hai.

$registers \leftarrow context (B), P C \leftarrow P C_{B} \Rightarrow B resumes$

Hum Step 5 ka union reverse karte hain: sab kuch wapas boxes mein pop karo.
$P C \leftarrow P C_{B}$ — last restore ki hui plate CPU ko B ke code mein redirect karti hai.

Step 8 — Edge aur degenerate cases (reader ko kabhi akela mat chhodho)

KYA HAI. Teen corners jo naive story ko tod dete hain — har ek drawn.

Case (a): trigger fire hota hai lekin highest Ready task abhi bhi A hai. Toh Step 6 mein scheduler A ko phir se choose karta hai — koi switch nahi hota, PendSV pend bhi nahi hota, aur hum poora $T_{cs}$ cost bacha lete hain. Kyun: switching tab hi worth it hai jab winner actually badla ho.

Case (b): equal priority (A aur B dono priority 2). Priority akele tie nahi tod sakta, toh preemption event par FIRE NAHI HOTA. Iske bajaye woh tick boundaries par baari baari lete hain — round-robin time-slicing. Kyun: preemption strictly higher-priority-driven hai; equals time share karte hain, ek doosre ko dhakka nahi dete.

Case (c): pehli baar switch — B ka stack "empty" hai. B kabhi run nahi hua, toh koi real saved photo nahi hai. Task creation par RTOS B ke fresh stack par ek fake exception frame hand-craft karta hai: ek PC jo B ke entry function ki taraf point kare, ek clean xPSR, aur dummy r0–r12. Step 7 phir is fake frame ko "restore" karta hai aur B apne top se start karta hai. Kyun: isse ek task create karna aur ek task resume karna bilkul same restore code use karte hain.

Ek-picture summary

Poora dance compress kiya: A running → trigger → A save karo (hardware 8 + software 8) → A ka SP TCB mein file karo → B ka SP load karo → B restore karo (software 8 + hardware 8) → B running. Do "8" photo ke do hisson hain; TCB ka akela SP woh string hai jo har photo ko uske owner se baandhti hai.

Recall Feynman retelling — ek story ki tarah bolo

Socho ek artist (CPU) jo ek waqt mein sirf ek painting hold kar sakta hai. Task A artist ko ek aadhi bani canvas deta hai. Ek ghanti bajti hai (trigger) jo kehti hai "urgent customer B aa gaya hai, aur B, A se upar hai." Toh artist jaldi se A ki canvas ki do angles se photo leta hai — camera khud aath cheezein snap karta hai (hardware push), artist khud se aath aur snap karta hai (software push) — aur photo A ki locker par ek sticky note ke saath staple karta hai jis par iska shelf number likha hai (SP into TCB). Artist B ki locker note padhta hai, B ki shelf par jaata hai, B ki purani photo un-staple karta hai, aur exactly wahan paint karta hai jahan B ne chhoda tha. B ko pata nahi chalta ki usne wait kiya. Agar B ki rank A ke barabar hoti, toh koi shoving nahi — woh bas ek kitchen timer par swap karte (round-robin). Aur pehli baar jab B kabhi show up karta hai, artist quietly B ki locker par ek blank template photo staple kar deta hai taaki "resume" ritual kaam kare. Yahi context switch hai — aur $η = T_{cs} f_{t i c k}$ woh chhota sa tax hai jo aap har baar ghanti bajne par dete hain.

Recall Khud test karo

Context switch do alag groups of registers kyun save karta hai? ::: Hardware, exception entry par r0–r3, r12, LR, PC, xPSR auto-push karta hai; software (PendSV) ko callee-saved r4–r11 push karne chahiye. Union = full context. Kaunsa akela value poore saved frame ko anchor karta hai, aur woh kahan store hota hai? ::: Stack pointer (SP), us task ke TCB mein store hota hai (savedSP field). PendSV ko lowest interrupt priority par kyun set kiya jaata hai? ::: Taaki switch sirf tab run ho jab saare real ISRs khatam ho jayein — urgent hardware servicing ke beech mein switching nahi. Do equal-priority tasks: kya koi event ek ko doosre ke liye preempt karta hai? ::: Nahi — preemption ke liye strictly higher priority chahiye. Equals ticks par round-robin time-slicing se share karte hain. Ek brand-new task in kaise switch hoti hai agar uske paas koi saved context nahi hai? ::: RTOS creation par ek fake exception frame hand-craft karta hai (PC = entry function, clean xPSR, dummy regs), taaki normal restore code kaam kare.

Related: Priority Inversion and Mutexes · Semaphores and Queues · Bare-metal super-loop vs RTOS