4.2.7
Intuition Ek-line pictureEk process ek ghar hai; ek thread uske andar kaam karne wala worker hai. Saare workers ek hi ghar share karte hain (address space , code, data, open files) lekin har ek ka apna stack aur registers hota hai (unka apna scratchpad). Is topic ka asli sawaal yeh hai: in workers ko kaun schedule karta hai — program khud, ya OS kernel? Yeh ek choice hi sab kuch decide karti hai — performance aur blocking dono ke baare mein.
Intuition Zyada processes kyun nahi?Ek process banana mehnga hai: poora address space ka copy, page tables, file tables. Ek hi process ke andar threads yeh sab share karte hain, isliye:
Creation/switching sasta hai (koi address-space switch nahi → koi TLB flush nahi).
Communication free hai (shared memory, koi IPC nahi).
Multi-core CPUs par, ek process ke threads sach mein parallel chal sakte hain.
Cost yeh hai: shared memory ka matlab hai race conditions → aapko locks chahiye (baad ka topic).
Ek thread CPU scheduling ki basic unit hai. Yeh process ka woh hissa hai jiska apna hota hai:
Program counter (PC), register set, stack , thread-ID, state.
Aur sibling threads ke saath share karta hai:
Code section, data/heap, open files, signals, process ka address space.
Ek process mein do threads — kya woh heap share karte hain? Stack? ::: Woh heap share karte hain (aur global data bhi), lekin har ek ka apna stack aur registers hote hain.
Definition User-level thread (ULT)Threads jo poori tarah ek user-space thread library se manage hote hain (jaise, purane green threads). Kernel sirf ek schedulable entity dekhta hai — poora process. Library us ek kernel slot ke andar apna scheduling khud karti hai.
Definition Kernel-level thread (KLT)Threads jo OS kernel dwara create aur schedule hote hain. Har thread ek kernel-known schedulable entity hoti hai (kernel mein ek TCB). Modern Linux/Windows threads KLTs hain.
Property
User-level (ULT)
Kernel-level (KLT)
Managed by
user library
OS kernel
Context switch cost
bahut sasta (koi trap nahi)
mehnga (mode switch)
Blocking call blocks...
whole process sirf woh thread
True multicore parallelism
❌ (1 kernel slot)
✔
OS ke across portable
✔
❌ (OS-specific)
Library user threads ko kernel threads par teen tarike se map kar sakti hai.
Definition Many-to-One (M:1)Kai user threads → ek kernel thread. Yeh pure ULT hai. Sasta hai, lekin ek blocking call sab ko block kar deti hai, aur koi multicore parallelism nahi (ek waqt mein sirf ek kernel slot chalta hai).
Definition One-to-One (1:1)Har user thread apne khud ke kernel thread par map hoti hai. Maximum concurrency + true parallelism; ek thread ka block hona doosron ko block nahi karta. Cost: ek kernel thread per user thread → kernel overhead se aap kitne bana sakte ho yeh limited hai. Linux pthreads, Windows threads yeh use karte hain.
Definition Many-to-Many (M:N)m n ≤ m
Worked example Worked: 100 web-server worker threadsSetup: Ek server mein 100 worker threads hain; ~30 aam taur par disk/network I/O par blocked rehte hain, 4 CPU cores hain.
Many-to-One: Jab 1 worker blocking read() call kare, kernel 1 process dekhta hai → sab 100 freeze . Yeh step kyun? Kernel sirf apni schedulable unit ko block kar sakta hai; usse baaki 99 ke ready hone ka pata nahi. Aur max parallelism = 1 core. Kharaab fit. One-to-One: 100 kernel threads. Jo 30 blocked hain woh kernel mein so jaate hain; baaki 70 chalte rehte hain, ek waqt mein 4 parallel. Yeh step kyun? Kernel har thread ko alag schedule karta hai. Acha hai , lekin 100 TCBs kernel memory cost karte hain.Many-to-Many (maan lo 100→6): 6 kernel threads. Jab ek user thread block ho, library doosre user thread ko ek free kernel thread par move kar sakti hai. Yeh step kyun? Hum 100 ka cost uthaye bina enough kernel threads (≥cores + blocking ke liye buffer) rakhte hain. Best balance.
Common mistake "User-level threads multiple cores par parallel chal sakte hain."Kyun sahi lagta hai: Aapne 8 threads create kiye aur expect kiya ki 8 cores busy hon.
Reality: Pure M:1 ULT mein kernel ek schedulable entity dekhta hai, isliye ek waqt mein ek hi chalta hai. Fix: True parallelism ke liye kernel ko multiple threads ke baare mein pata hona chahiye → 1:1 ya M:N.
Common mistake "Kernel-level threads hamesha better hote hain."Kyun sahi lagta hai: Woh blocking call par process freeze nahi karte aur parallelism dete hain.
Fix: Har operation ek system call (mode switch) hai. Bahut zyada short-lived threads ke liye, KLT overhead hurt karta hai — isliye M:N aur modern user-space schedulers (goroutines) aate hain.
Common mistake "Ek process ke threads ke alag address spaces hote hain."Kyun sahi lagta hai: Processes ke hote hain, aur threads similar lagte hain.
Fix: Threads address space share karte hain; sirf stack + registers private hote hain. Yahi sharing hai jiske liye locks chahiye hote hain.
Common mistake "Many-to-One ka matlab hai many CPUs to one thread."Kyun sahi lagta hai: Naming ambiguous hai.
Fix: "Many" = kai user threads, "One" = ek kernel thread jisme woh sab map hote hain.
Threaded process mein CPU scheduling ki unit kya hai? Thread (har ek ka apna PC, registers, stack hota hai).
Sibling threads kya share karte hain aur kya private rakhte hain? Share: code, data/heap, open files, address space. Private: stack, registers, PC, thread state.
User-level threads ko kaun schedule karta hai? Ek user-space thread library; kernel sirf ek process dekhta hai.
Many-to-One mein, jab ek thread blocking system call kare toh kya hota hai? Puri process block ho jaati hai (kernel sirf ek schedulable entity dekhta hai).
User-level thread switches kernel-level ones se saste kyun hote hain? Koi mode switch / kernel mein trap nahi — switching sirf user-space bookkeeping hai.
Kaun sa mapping model sabse kam kernel overhead per user thread ke saath true multicore parallelism deta hai? Many-to-Many (M:N).
Modern Linux pthreads aur Windows kaun sa model use karte hain? One-to-One (1:1).
M:N mein m user aur n kernel threads ke saath n par constraint kya hai? n ≤ m n ≥
One-to-One ka main drawback kya hai? Ek kernel thread (TCB) per user thread → kernel overhead thread count limit karta hai.
Threads ko synchronization kyun chahiye lekin alag processes ko mostly nahi? Threads memory share karte hain (heap/globals) → race conditions.
Mnemonic Models yaad karo"M1 freezes, 1:1 flies, MN balances."
M:1 → ek blocking call sabko freeze kar deti hai, koi parallelism nahi.1:1 → har ek free fly karta hai (parallel) lekin kernel pay karta hai.M:N → cost vs concurrency balance karta hai.
Aur "Who Knows, Who Blocks" : jo threads ko Jaanta hai (user lib vs kernel) wahi decide karta hai ki kya Block hoga.
Recall Feynman: ek 12-saal ke bachche ko samjhaoEk kitchen imagine karo (process). Cooks threads hain — woh sab ek hi fridge, counter, aur ingredients share karte hain (shared memory), lekin har cook ka apna chota sa chopping board hota hai (stack).
Ab, cooks ko kab kaam karna hai yeh kaun batata hai?
Agar kitchen ke andar head chef karta hai (user-level), toh poore restaurant ka manager (kernel) sochta hai ki kitchen sirf ek worker hai. Toh agar ek cook basement ke freezer mein jaake stuck ho jaaye (blocking call), manager sochta hai puri kitchen ruk gayi aur stove doosri kitchen ko de deta hai — chahe baaki cooks ready hon!
Agar restaurant manager har cook ko directly schedule kare (kernel-level), sirf stuck cook wait karta hai; baaki cooking karte rehte hain — aur woh kai stoves ek saath use kar sakte hain (cores). Lekin manager se har choti cheez ke liye poochna slow hai.
Many-to-Many : kuch cooks rakh lo jinhe manager jaanta ho, aur extra helpers ko woh slots share karne do — fast bhi aur poori kitchen freeze bhi nahi hoti.
Process vs Thread Context Switching CPU Scheduling Race Conditions and Synchronization System Calls and Mode Switch Goroutines and M-N Scheduling TLB and Address Space Switching
Costly but true parallelism
