Visual walkthrough — std - condition_variable

5.2.25 · D2 · Coding › C++ Programming › std - condition_variable

Step 0 — Teen words jo hum use karenge (pehle vocabulary earn karo)

Kisi bhi diagram se pehle, teen plain-word definitions. Neeche koi bhi aisa word use nahi hoga jo yahan define na ho.

Apne dimaag mein yeh char pictures rakho: worker, key, waiting-room-with-doorbell, shared box. Baaki sab yahi char cheezein move karti hain.

Step 1 — Naive attempt, aur kyun yeh jalti hai

KYA. Consumer queue se ek number chahta hai. Pehla idea jo koi beginner likhta hai:

while (queue.empty()) { /* keep looping */ }   // busy-wait

KYun tempting lagta hai. Yeh literally English sentence hai "jab tak empty hai, check karte raho." Yeh kaam karta hai.

KYun galat hai. Picture dekho. Consumer empty() ko ek second mein lakho baar check kar raha hai. Har check kuch useful nahi karta — box abhi bhi empty hai — lekin CPU 100% pe pinned hai. Ek core wali machine pe, consumer kabhi producer ko run nahi karne deta, toh box hamesha empty rehta hai. Isse busy-wait kehte hain, aur yahi woh bimari hai jise hum theek karne wale hain.

Step 2 — Shared box, ek key se guarded

KYA. Hum shared state aur uska guard setup karte hain:

std::queue<int> q;          // numbers ka shared box
std::mutex      m;          // q ko touch karne ki EK key
std::condition_variable cv; // waiting room + doorbell
bool done = false;          // "producer khatam ho gaya" flag

KYon. Do workers ko kabhi bhi q ek hi instant mein touch nahi karna chahiye — yeh ek Race Condition hai. Rule: q ya done touch karne se pehle key m hold karo. cv alag hai: yeh kuch protect nahi karta, yeh sirf sleepers ko park aur wake karta hai.

PICTURE. Box q ek locked room ke andar hai. Single key m ek hook pe lagi hai. Side mein cv ka waiting room hai apni doorbell ke saath. Abhi koi key hold nahi kar raha.

Step 3 — Consumer key leta hai, phir box empty milta hai

KYA.

std::unique_lock<std::mutex> lk(m);          // key pakdo
cv.wait(lk, []{ return !q.empty() || done; }); // check karo, shayad so jao

Aao us doosri line ke pieces ko term by term name karte hain: $\text{cv.wait}(\underset{\text{the key it holds}}{\underbrace{\text{lk}}},\underset{\text{the predicate }P()=\text{"is there work OR are we done?"}}{\underbrace{[]\{\text{return }!\text{q.empty()}||\text{done};\}}})$

KYon unique_lock aur lock_guard nahi? Ek step mein wait ko key chodna padta hai (taaki producer use pakad sake) aur baad mein wapas lena padta hai. Yeh hai unlock-then-relock — ek std::unique_lock dono kar sakta hai; ek std::lock_guard sirf ek baar lock kar sakta hai aur kabhi nahi chhod sakta. Isliye waiter ko zaroor unique_lock use karna chahiye.

KYon predicate P()? P() woh honest sawaal hai "kya mujhe jaag rahe rehna chahiye?" Abhi box empty hai aur done false hai, toh P() false hai. Kyunki P() false hai, wait decide karta hai: jaag kar rehne ka koi fayda nahi → yeh key release karta hai aur so jaata hai.

PICTURE. Consumer key hold karta hai, box mein jhankta hai, empty pata hai. P() amber mein false dikhta hai.

Step 4 — Atomic magic: wait key drop karta hai aur so jaata hai

KYA. Kyunki P() false tha, wait(lk) teen cheezein ek indivisible move mein karta hai: $\underset{\text{key wapas hook pe jaati hai}}{\underbrace{\text{unlock}(lk)}}\to \underset{\text{waiting room mein jaao, 0\% CPU}}{\underbrace{\text{sleep}}}\to \underset{\text{wake hone pe key wapas lo}}{\underbrace{\text{(baad mein) re-lock}(lk)}}$

KYon "atomic" matter karta hai. "P() check karo" aur "so jao" ke beech koi gap nahi hona chahiye. Agar gap hota, producer us gap mein doorbell baja sakta tha — aur consumer, abhi tak soya nahi, use miss kar deta aur hamesha ke liye so jaata. Yeh lost wakeup race hai (iske opposite problem ke liye Spurious Wakeup bhi dekho). Standard promise karta hai: key release karna aur sona shuru karna saath hote hain, toh notify kabhi kisi crack mein nahi ghus sakta.

PICTURE. Consumer ka chehra ab waiting room mein soya hua hai. Key m wapas hook pe hai — producer ke liye free. CPU meter 0% dikhata hai.

Step 5 — Producer kaam karta hai aur doorbell bajata hai

KYA.

{
    std::lock_guard<std::mutex> lk(m);  // free key pakdo
    q.push(0);                          // box mein ek number daalo
}                                       // key YAHAN release hoti hai (scope khatam)
cv.notify_one();                        // doorbell bajao

KYon producer lock_guard use kar sakta hai. Producer ko sirf lock, mutate, ek baar unlock karna hai. Yeh kabhi nahi sota, toh ise kabhi unlock/relock nahi chahiye — simpler std::lock_guard yahan correct hai.

KYon notify karne se pehle key release karo? Agar hum key hold karte hue bell bajate hain, toh jaga hua consumer turant key pakdne ki koshish karta hai, use liya hua paata hai, aur firse block ho jaata hai — ek bekar bounce. Pehle release karne ka matlab hai consumer ko available key milti hai jaagne ke baad. (Yeh ek optimization hai; lock ke andar notify karna bhi correct hai.)

PICTURE. Producer key hold karta hai, box mein 0 dalta hai, key wapas latkata hai, phir amber doorbell dabaata hai. Ek wake-signal waiting room ki taraf jaata hai.

Step 6 — Consumer jaagta hai, dobara check karta hai, aur tabhi kaam karta hai

KYA. Doorbell sleeper ko jagaati hai. wait ab key re-lock karta hai aur P() dobara evaluate karta hai: $P()=\text{!q.empty()}||\text{done}=\text{true}(\text{box mein }0\text{ hai})$ Toh wait return karta hai, consumer key hold karta hai, aur box drain karta hai.

KYon dobara check karo — kya bell ka matlab "jao" nahi tha? Nahi. Do cheezein aapko jhooth bol sakti hain:

1. Ek spurious wakeup — OS ek sleeper ko bina kisi ke bell bajaye jagaa sakta hai. Dekho Spurious Wakeup.
2. Ek stolen wakeup — kai consumers ke saath, doosra consumer single item pehle grab kar sakta hai, is consumer ke liye box empty chhodke.

Predicate loop safety net hai. Formally predicate overload ek loop hi hai: $\text{cv.wait(lk, P)}\equiv \text{while(!P()) cv.wait(lk);}$ Term by term: while P() abhi bhi false hai, wapas so jao; sirf tab niklo jab P() genuinely true ho. Isliye hum yahan kabhi if use nahi karte.

PICTURE. Consumer jaag gaya, haath mein key hai, P() ab green/true hai, box se 0 nikaal raha hai.

Step 7 — Edge cases jo aap skip nahi kar sakte

Real code corners se milta hai. Yeh sab hain, har ek ke liye apna frame.

Case A — Spurious wakeup (kisi ne bell nahi bajaayi). Consumer khud jaag jaata hai. Yeh re-lock karta hai, P() = false evaluate karta hai (box abhi bhi empty hai), aur while use seedha wapas so bhejna deta hai. Koi nuksan nahi — kyunki humne loop kiya.

Case B — Notify jab koi wait nahi kar raha (lost notify). Ek condition_variable ki koi memory nahi hoti. Agar producer bell bajata hai jab consumer abhi waiting room mein gaya nahi hai, toh woh ring void mein ghum jaati hai. Yeh theek hai sirf isliye kyunki number already box mein rakha hua hai — jab consumer finally P() check karta hai, toh box (shared flag) sach bolta hai. Lesson: correctness shared state mein rehti hai, ring mein nahi.

Case C — Shutdown (done = true, notify_all). Jab producer khatam ho jaata hai:

{ std::lock_guard<std::mutex> lk(m); done = true; }
cv.notify_all();   // HAR sleeper ko jagao taaki woh exit kar sakein

notify_all sab consumers ko jagaata hai; har ek done se P() true dekhta hai, kuch bacha ho toh drain karta hai, aur exit karta hai. Yahan notify_one use karne se doosre consumers hamesha ke liye sote reh sakte hain — ek Deadlock-jaisi hang.

Ek-picture summary

Yeh single frame Steps 2–7 compress karta hai: producer aur consumer ke beech key ka pass hona, sleep-with-key-released move, doorbell, aur re-check loop.

🇮🇳 Yeh note Hinglish mein padho → · See also Producer-Consumer Pattern, std::future and std::promise, std::atomic.