std - condition_variable — Hinglish notes

5.2.25 · Coding › C++ Programming

WHY does this exist?

Definition Woh problem jo yeh solve karta hai

Socho ek consumer thread jo queue se ek item chahti hai. Naive tarika:

while (queue.empty()) { /* spin */ }   // BUSY WAIT — burns 100% CPU

Yeh CPU waste karta hai spinning mein, aur single core par toh producer ko starve bhi kar sakta hai. Hum chahte hain ki consumer soye (0% CPU use kare) aur tabhi jaage jab koi item aaye. Ek condition_variable ek thread ko atomically mutex release karne aur so jaane deta hai, phir mutex re-acquire karne aur notify hone par jaagna deta hai.

WHAT yeh hai: ek synchronization primitive (#include <condition_variable>) jo std::mutex ke saath milke kaam karta hai (std::unique_lock ke zariye) taaki threads kisi condition ka wait kar sakein.

HOW teen pieces fit hote hain:

Ek shared condition (jaise bool ready, ek queue) jo mutex se protected hai.
Waiter: mutex lock karo → cv.wait(lock, pred) call karo → atomically unlock + so jao.
Notifier: mutex lock karo → condition change karo → cv.notify_one()/notify_all() call karo.

The core API (derived by reasoning, not memorized)

Kyun predicate while hai, if nahi? Standard mein do reasons bake hain:

Spurious wakeups: OS ek waiting thread ko bina kisi notify ke bhi jaga sakta hai. Loop re-check karta hai aur wapas so jaata hai.
Stolen wakeups: notify_all ke saath, kai threads jaagti hain, lekin lock grab karne wali pehli thread akela item consume kar sakti hai. Loop doosron ko re-check karke wapas sone par majboor karta hai.

Producer–consumer queue ko scratch se derive karna

Humein chahiye: shared std::queue<int>, ek std::mutex m, ek std::condition_variable cv.

#include <condition_variable>
#include <mutex>
#include <queue>
#include <thread>
#include <iostream>
 
std::queue<int> q;
std::mutex m;
std::condition_variable cv;
bool done = false;
 
void producer() {
    for (int i = 0; i < 5; ++i) {
        {
            std::lock_guard<std::mutex> lk(m); // lock to mutate shared state
            q.push(i);
        } // unlock BEFORE notify (small optimization, avoids waiter waking & blocking)
        cv.notify_one();                       // ring the doorbell
    }
    {
        std::lock_guard<std::mutex> lk(m);
        done = true;
    }
    cv.notify_all();                           // wake everyone so they can exit
}
 
void consumer() {
    while (true) {
        std::unique_lock<std::mutex> lk(m);    // unique_lock: wait can unlock/relock it
        cv.wait(lk, []{ return !q.empty() || done; }); // sleep until pred true
        while (!q.empty()) {
            int v = q.front(); q.pop();
            std::cout << "got " << v << "\n";
        }
        if (done && q.empty()) break;          // nothing left and producer finished
        // lk auto-unlocks at end of loop scope
    }
}

Worked example Timeline walk (Har step kyun?)

Consumer m lock karta hai, wait(lk, pred) call karta hai. Kyun? Pred false hai (queue empty, done nahi) → wait m unlock karta hai aur so jaata hai. CPU ab free hai.
Producer m lock karta hai, 0 push karta hai, unlock karta hai, notify_one() call karta hai. Kyun pehle unlock? Agar hum lock hold karte hue notify karein, toh jaagi hui consumer turant lock karne ki koshish karegi aur block ho jayegi — bekar context switch.
Consumer jaagti hai (spurious ya real), wait re-locks m, pred evaluate karta hai. Kyun re-check? Spurious wakeup ho sakta hai; loop correctness guarantee karta hai.
Pred true → consumer queue drain karta hai, 0 process karta hai. Loop continue karta hai.
Producer done=true set karta hai, notify_all() karta hai. Kyun notify_all yahan? Multiple consumers so rahi ho sakti hain; sabko done dekhne aur exit karne ke liye jaagna chahiye.

Doosra example: ek one-shot "go" signal

Worked example Exactly ek baar kisi event ka wait karo

std::mutex m; std::condition_variable cv; bool ready = false;
 
void worker() {
    std::unique_lock<std::mutex> lk(m);
    cv.wait(lk, []{ return ready; });   // sleep until ready==true
    std::cout << "started!\n";
}
void main_thread() {
    { std::lock_guard<std::mutex> lk(m); ready = true; } // set under lock
    cv.notify_one();
}

Kyun ready ko lock ke andar set karein? Agar aap ise lock ke bina set karte ho, toh aap lost-wakeup race mein pad sakte ho: worker ready==false check karta hai, phir sone se pehle notifier ready flip karta hai aur notify void mein chali jaati hai — worker hamesha ke liye so jaata hai. Lock karna "check" vs "set + notify" ko serialize karta hai.

Common mistakes (Steel-manned)

Flashcards

std::condition_variable kis header mein declare hota hai?

<condition_variable>

Ek thread cv.wait mein kaunsa lock type pass karta hai aur kyun?

std::unique_lock<std::mutex>, kyunki wait ko atomically mutex unlock phir re-lock karna hota hai (lock_guard yeh nahi kar sakta).

cv.wait(lock) atomically kya karta hai?

Mutex unlock karta hai, thread ko notify hone tak sula deta hai, phir return karne se pehle mutex re-acquire karta hai.

Kyun wait condition ko ek loop mein check karna padta hai (ya predicate overload ke zariye)?

Spurious wakeups aur stolen wakeups handle karne ke liye (doosri thread pehle resource consume kar le).

notify_one aur notify_all mein kya fark hai?

notify_one ek waiting thread ko jagata hai; notify_all unhe sabko jagata hai (woh phir lock ke liye contend karte hain).

Notify karne se pehle mutex hold karte hue shared state kyun modify karein?

Lost-wakeup race avoid karne ke liye jahan waiter notification miss kar sake aur hamesha ke liye so jaye.

Kya condition_variable un notifications ko yaad rakhta hai jo tab bheji gayi jab koi wait nahi kar raha tha?

Nahi — notifications lost ho jaati hain agar koi thread currently wait nahi kar rahi; correctness shared predicate/flag se aani chahiye.

Kya notify call karte waqt lock hold karna zaruri hai?

Zaruri nahi, lekin safe pattern yeh hai ki state ko lock ke andar change karo; optimization ke tor par notify karne se pehle unlock kar sakte ho.

cv.wait(lk, pred) kis cheez ke equivalent hai?

while(!pred()) cv.wait(lk);

Recall Feynman: ek 12-saal ke bachche ko explain karo

Socho tum ek worker ho jo pizza ka wait kar rahe ho. Har second oven check karne ki jagah (thakaan = energy waste), tum couch par so jaate ho. Ek rule hai: sone se pehle tum chef se kaho "ready hone par jagao" — aur kitchen chhod do taaki chef cook kar sake. Pizza ready hone par chef chillata hai ("notify!") aur tum jaag jaate ho, double-check karte ho ki pizza sach mein wahan hai (shayad tumne sirf sapna dekha — yeh spurious wakeup hai), aur phir khaate ho. Couch nap = wait, chillana = notify, double-checking = while loop. Is tarah tum sote waqt koi energy use nahi karte lekin kabhi apna pizza miss nahi karte.

Connections

std::mutex — woh lock jiske saath condition_variable cooperate karta hai.
std::unique_lock — wait ke liye required; unlock/relock enable karta hai.
std::lock_guard — simpler RAII lock, notifier side mein use hota hai.
Producer-Consumer Pattern — canonical use case.
std::future and std::promise — higher-level one-shot signaling.
Spurious Wakeup — predicate loop ki wajah.
std::atomic — lock-free flags ka alternative (lekin efficient blocking nahi).
Race Condition / Deadlock — woh bugs jo proper use se prevent hote hain.