RTOS concepts — task, scheduler, preemption, context switch: Question bank

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

Definition Is page par use kiye gaye symbols (pehle define karo)

$T_{cs}$ = context-switch time: wo seconds jo outgoing task ke registers save karne aur incoming task ke registers restore karne mein lagte hain — har switch par diya jaane wala "toll."
$f_{t i c k}$ = tick frequency: periodic timer interrupt ("tick") ek second mein kitni baar fire hoti hai, hertz mein. 1000 Hz tick har 1 ms mein fire hoti hai.
$η$ (Greek "eta") = overhead fraction: total CPU time ka wo hissa jo real kaam karne ki bajaye switching mein barbad hota hai, 0 aur 1 ke beech fraction ke roop mein likha jaata hai (0.002 = 0.2%). Yeh dono upar wale ko $η = T_{cs} \cdot f_{t i c k}$ ke roop mein jodata hai.
$T_{i sr}$ = interrupt latency: ek hardware event se lekar uske interrupt handler ki pehli instruction tak ke seconds. Dekho Interrupts and ISR latency.

Picture 1 — switch par CPU kya save karta hai

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

Recall Har acronym ka matlab

r0–r3, r12 ::: general-purpose scratch registers jo current computation ki intermediate values hold karte hain. LR (Link Register) ::: return address — jab current function khatam hota hai toh execution wahan jump karti hai. PC (Program Counter) ::: agle instruction ka address jo run hoga — "main code mein kahan hoon." xPSR (Program Status Register) ::: condition flags (zero, carry, negative) jo recent operations ka result record karte hain. r4–r11 ::: aur general registers jo compiler longer-lived locals ke liye use karta hai; hardware inhe auto-save nahi karta, isliye PendSV ko karna padta hai. SP (Stack Pointer) ::: is task ki private stack ke top par point karta hai; TCB mein puri frame ka handle ke roop mein store hota hai.

Picture 2 — timeline par preemption

Picture 3 — priority inversion aur uska fix

True or false — justify karo

More tasks matlab single-core MCU par zyada parallel speed

False. Ek core exactly ek instruction stream run karta hai; extra tasks switching overhead aur stack RAM add karte hain. Yeh responsiveness aur structure dete hain, throughput nahi. Dekho Bare-metal super-loop vs RTOS.

Zyada tick frequency system ko "more real-time" banati hai

False. Event-driven preemption already interrupts ke through instantly fire hoti hai; tick sirf time-based delays ko pace karta hai. Ise uthana bas CPU ko

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

ke roop mein jalaata hai.

Context switch mein sirf program counter save karna kaafi hai

False. Sirf PC general registers, status flags, aur stack pointer ke bina useless hai — unme task ka live data hota hai (dekho Picture 1). Unhe kho do aur task garbage par resume karega.

Do equal-priority tasks ek doosre ko preempt kar sakte hain

False. Preemption strictly priority-driven hai. Equal-priority tasks CPU ko tick boundaries par round-robin time-slicing se share karte hain, preempt karke nahi.

Ek Blocked task wait karte waqt bhi CPU cycles consume karta hai

False. Blocked tasks run karne ke eligible nahi hote, isliye scheduler simply unhe skip karta hai — exactly yahi reason hai ki blocking (busy-waiting nahi) CPU ko doosron ke liye free karta hai.

Fixed-priority preemptive scheduling mein, highest-priority Ready task hamesha CPU own karta hai

True. Yahi defining rule hai. Sirf yeh caveats hain jab ISR run ho raha ho ya brief context-switch window ke dauran.

Preemption ke liye running task ko cooperate karna ya yield karna padta hai

False. Yeh cooperative scheduling describe karta hai. Preemption forcibly running task ko pause kar deta hai jis instant koi higher-priority task Ready hota hai — koi cooperation nahi chahiye (dekho Picture 2).

Cortex-M par, hardware exception entry par entire register set auto-save karta hai

False. Hardware sirf r0–r3, r12, LR, PC, xPSR (8 registers) auto-push karta hai; software PendSV handler ko abhi bhi r4–r11 push karne padte hain full state capture karne ke liye — exactly woh split jo Picture 1 mein dikhaya gaya hai.

Scheduler sirf periodic tick interrupt par run hota hai

False. Yeh kisi bhi event ke baad bhi run hota hai jo kisi higher-priority task ko unblock kar sake (jaise ISR se semaphore give), isliye preemption immediate hoti hai, tick-delayed nahi. Dekho Semaphores and Queues.

Spot the error

while(!data_ready); ek task ke andar, UART data ke liye 5 ms wait karte hue

Task Running rehta hai aur 5 ms ke liye CPU hog karta hai, lower-priority kaam ko starve karta hai. Fix: xQueueReceive jaisi blocking call use karo taaki task Blocked mein enter kare aur scheduler doosron ko run kare.

"1 ms deadline meet karne ke liye, main tick ko 100 kHz tak raise karunga."

Time-slicing ko event response ke saath confuse karta hai. Deadline priority + interrupts ke through preemption se meet hoti hai, tick rate se nahi. 2 µs switch ke saath 100 kHz tick 20% CPU kisi kaam ke liye barbad karta hai.

"WiFi stack aur motor loop dono ko same high priority do taaki dono fast hon."

Equal priority matlab woh round-robin karenge aur ek doosre ko ek full time slice se delay kar sakte hain. Hard-real-time motor loop strictly higher honi chahiye taaki woh hamesha WiFi kaam ko preempt kare.

"Sirf PC ko TCB mein save karna context switch ke liye kaafi hai."

TCB saved stack pointer store karta hai, jo us task ke stack par puri register frame ka handle hai — sirf PC nahi. Dekho Stack memory and TCB.

"PendSV ko highest interrupt priority honi chahiye taaki switches fast hon."

Ulta hai. PendSV ko lowest priority set ki jaati hai taaki switch sirf saare real ISRs khatam hone ke baad ho, nested-switch chaos se bachte hue. Dekho Interrupts and ISR latency.

"Ek low-priority task safely ek high-priority task ko block kar sakta hai agar woh kabhi resources share nahi karte."

Tab sirf sach hai jab woh truly kuch share nahi karte. Jis moment woh ek mutex share karte hain, ek low task jisne use hold kiya hai high task ko block kar sakta hai — yahi priority inversion hai (Picture 3). Dekho Priority Inversion and Mutexes.

"Main plain mutex use karta hoon, isliye ek medium task mere high task ko kabhi delay nahi kar sakta."

Priority inheritance ke bina galat hai: ek medium task low lock-holder se aage run kar sakta hai, high task ko indefinitely stall karta hua. Ek priority-inheritance ya priority-ceiling mutex isko rokta hai. Dekho Priority Inversion and Mutexes.

Why questions

Har task ka apna alag stack kyun hona chahiye?

Har task apne return addresses, local variables, aur register frame apne stack par save karta hai; ek stack share karna tasks ko har switch par ek doosre ka live state overwrite karne deta.

Scheduler priority aur readiness se kyun pick karta hai, sirf priority se nahi?

Highest-priority task Blocked ho sakta hai (kisi event ka wait kar raha ho). Use run karna impossible hoga, isliye scheduler highest-priority task pick karta hai jo actually Ready hai.

Busy-waiting ko CPU "churaana" aur blocking ko "release karna" kyun kaha jaata hai?

Busy-waiting task ko Running rakhta hai, isliye scheduler CPU kisi aur ko nahi de sakta; blocking task ko Blocked mein flip kar deta hai, CPU ko doosre Ready tasks ke liye immediately free karta hai.

Context-switch overhead tick frequency ke saath kyun scale karta hai?

Ek second mein

f_{t i c k}

ticks hote hain; agar har worst-case tick ek switch force karta hai jo

T_{cs}

leta hai, toh barbad fraction

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

hai — tick rate mein linear.

Highest-priority task ka response time sirf

T_{i sr} + T_{cs}

se kyun bounded ho sakta hai?

Kyunki ise delay karne ke liye higher priority ka kuch exist nahi karta — sirf triggering ISR khatam karna (

T_{i sr}

) aur ek context switch (

T_{cs}

) event aur uski pehli instruction ke beech khade hain. Lower tasks blocking terms add karte hain (dekho Rate Monotonic Scheduling).

Preemption un deadlines meet karne mein kyun help karta hai jo cooperative scheduling miss kar deta?

Cooperative scheduling running task ke yield karne ka wait karta hai, jo deadline ke kaafi baad ho sakta hai; preemption use us instant pause kar deta hai jab urgent task Ready hota hai, isliye latency doosre task ke code par depend nahi karta.

"Ek core ek instruction stream run karta hai" zyatatar RTOS misconceptions ke peeche key fact kyun hai?

Yeh us illusion ko khatam karta hai ki tasks truly parallel run hote hain — concurrency fast switching se fake ki jaati hai, isliye extra tasks speed ki bajaye overhead add karte hain. True parallelism ke liye multiple cores chahiye.

Priority inheritance inversion solve karta hai lekin plain mutex kyun nahi?

Inheritance temporarily low lock-holder ko waiting high task ki priority tak raise kar deta hai, isliye koi medium task aage jump nahi kar sakta; plain mutex holder ko uski low priority par chod deta hai, medium-task interference ke exposed. Dekho Priority Inversion and Mutexes.

Edge cases

Agar ek waqt mein har task Blocked ho toh kya hota hai?

Koi task Ready nahi hai, isliye scheduler idle task run karta hai — ek lowest-priority do-nothing task jo CPU ko alive rakhta hai (aksar power ke liye so jaata hai) jab tak koi event kisi ko unblock na kare.

"Tickless idle" kya hai aur yeh no-task case ko kaise change karta hai?

Jab saare tasks Blocked hoon, kernel periodic tick band kar deta hai aur MCU ko deep sleep mein le jaata hai, har millisecond ki bajaye agle timed event par wake hota hai. Yeh idle power drastically kam karta hai aur needless tick-driven switches hatata hai, isliye

η

idle rehte waqt effectively zero ho jaata hai.

Kya tickless idle context-switch overhead count karne ke tarike ko change karta hai?

Haan — "ek switch per tick" worst case sirf tab apply hota hai jab tasks runnable hoon. Tickless sleep ke dauran koi ticks fire nahi hote, isliye koi switches nahi hote; overhead sirf tab pay ki jaati hai jab real kaam resume hota hai.

Agar do equal, highest priority ke tasks dono Ready hoon toh kya hota hai?

Na hi doosre ko preempt kar sakta hai; woh CPU ko round-robin time-slicing se share karte hain, har ek scheduler ke rotate hone se pehle ek tick run karta hai.

Kya context switch tab bhi chahiye jab tick ke baad wohi task run karta rahe?

Nahi. Agar highest-priority Ready task abhi bhi current wala hai, scheduler use re-select karta hai aur register save/restore skip karta hai — koi switch cost pay nahi hoti.

Kya hoga agar ek high-priority task Ready ho jaaye jab ISR abhi bhi run ho raha ho?

Switch tab tak defer hota hai jab tak ISR (aur koi bhi pending higher-priority ISRs) khatam na ho jaaye — yahi reason hai ki PendSV lowest interrupt priority par baithta hai. Task phir jaise hi CPU thread mode mein return karta hai preempt kar leta hai.

Agar

T_{cs}

zero ki taraf shrink ho, toh kya tick raise karna free ho jaata hai?

Limit mein

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

, isliye switch cost gayab ho jaati hai — lekin tick ISR itself abhi bhi cycles aur cache disruption leta hai, isliye yeh kabhi truly free nahi hota.

Ek task voluntarily yield karta hai lekin woh akela Ready task hai — aage kya run hota hai?

Khud. Equal-or-higher priority ka koi aur Ready task nahi hone ke saath, scheduler wohi task re-select karta hai, isliye bina contender ke yield effectively no-op hai.

Priority inheritance active hone ke saath, us moment kya hota hai jab low task mutex release kare?

Uski temporary priority boost uske original level par wapas drop ho jaati hai aur waiting high task immediately lock acquire karta hai aur preempt karta hai — inversion window band ho jaati hai. Dekho Priority Inversion and Mutexes.