Exercises — std - condition_variable

==<condition_variable>==. Yeh dono std::condition_variable aur std::condition_variable_any declare karta hai. Note karo ki jis mutex ke saath yeh partner karta hai uske liye <mutex> alag se bhi chahiye.

Yeh ==std::unique_lock<std::mutex>== hona chahiye. Reason: wait ko sone se pehle mutex unlock karna hota hai (taaki notifier mutex le sake aur shared data change kar sake), phir jaagne ke baad re-lock karna hota hai. Ek std::lock_guard apne constructor mein ek baar lock karta hai aur destructor mein ek baar unlock karta hai — yeh koi unlock()/lock() expose nahi karta jo mid-life call ho sake. Sirf std::unique_lock ko repeatedly unlock aur re-lock kiya ja sakta hai, joh exactly wahi hai jo wait ko chahiye.

notify_one() sirf ek waiting thread ko jagata hai (OS decide karta hai kaun sa). notify_all() sabhi currently-waiting threads ko jagata hai; phir woh ek-ek karke mutex ke liye contend karte hain.

Bug 1 (line A): lock_guard ko wait unlock/re-lock nahi kar sakta. Ise std::unique_lock<std::mutex> lk(m); mein badlo. Bug 2 (line B): if + plain wait(lk) ek Spurious Wakeup ya stolen wakeup se nahi bachta — thread ready ke abhi bhi false rehne par bhi jaag sakta hai aur aage badh sakta hai. Predicate loop use 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; });   // == while(!ready) cv.wait(lk);
    // ... proceed, mutex held
}

Predicate overload while(!pred()) cv.wait(lk); ke roop mein define hai. Toh:

while (q.empty()) cv.wait(lk);

Dono equivalent hain; guarantee loop se aati hai, notification se nahi.

void main_thread() {
    { std::lock_guard<std::mutex> lk(m); ready = true; } // lock ke ANDAR set karo
    cv.notify_one();                                     // phir bell bajao
}

ready ko usi mutex ke under set karna jo waiter use karta hai, "waiter predicate check kare" aur "notifier flag set kare" ko serialize karta hai, jisse lost-wakeup window band ho jaati hai.

Correctness: flag (q non-empty) lock ke under set hota hai, isliye koi wakeup lost nahi ho sakta — waiter, jab mutex ke under predicate dobara check karega, item dekhega. Notify order correctness ko affect nahi karta kyunki flag sachai carry karta hai. Optimization (figure dekho): agar hum mutex hold karte hue notify karein (left timeline), toh jaaga hua consumer turant m lock karne ki koshish karta hai, producer ke paas held paata hai, aur phir se block ho jaata hai — ek waste hua wake→block→wake ping-pong. Unlock ke baad notify karne par (right timeline) consumer ek free mutex par jagta hai aur seedha aage badh jaata hai. Ise kabhi kabhi "hurry up and wait" problem kehte hain, aur pehle unlock karna isse bachata hai.

Sirf ek consumer jagta hai, done dekhta hai, aur exit karta hai. Doosra consumer abhi bhi so raha hai — use ab koi dobara notify nahi karega (production khatam ho gayi), isliye yeh hamesha ke liye hang kar jaata hai (Deadlock / permanent block ki ek form). Fix: terminal done transition par cv.notify_all() use karo taaki har waiter jage, dobara check kare, done dekhe, aur exit kare.

Inner while (!q.empty()) ek hi wake mein queue ki sab kuch drain kar deta hai. Agar saare 5 present hain toh yeh 0,1,2,3,4 print karta hai — woh 5 values hain, sum $0+1+2+3+4=10$.

Tumhe do condition variables chahiye jo ek mutex share karein:

• cv_not_full — producers isme wait karte hain; predicate q.size() < N.
• cv_not_empty — consumers isme wait karte hain; predicate !q.empty().

std::mutex m;
std::condition_variable cv_not_full, cv_not_empty;
std::queue<int> q;
const size_t N = 8;
 
void produce(int x) {
    std::unique_lock<std::mutex> lk(m);
    cv_not_full.wait(lk, []{ return q.size() < N; });
    q.push(x);
    lk.unlock();
    cv_not_empty.notify_one();
}
int consume() {
    std::unique_lock<std::mutex> lk(m);
    cv_not_empty.wait(lk, []{ return !q.empty(); });
    int v = q.front(); q.pop();
    lk.unlock();
    cv_not_empty.notify_one();      // galat bell? note dekho
    return v;
}

Solution ke andar correction: jab ek consumer ek item remove karta hai toh use cv_not_full.notify_one() bajani chahiye (ek slot khula), aur jab producer ek item add karta hai toh cv_not_empty.notify_one() bajata hai. Har side doosri side ko jagaati hai. Dono ke liye ek CV use karne par har baar notify_all() force hoga aur wakeups waste honge — do CVs har notify ko precise banaate hain. State diagram dekho:

(a) N = 0: producer predicate q.size() < 0 kabhi bhi true nahi hota (size unsigned hai, hamesha $\ge 0$), isliye har producer hamesha ke liye block ho jaata hai — ek deadlock. Capacity-0 buffer degenerate hai; ek real "rendezvous" (size-0 handoff) ke liye alag design chahiye jahan producer aur consumer directly milte hain. (b) N bahut bada: cv_not_full predicate hamesha true hai, isliye producers actually kabhi wait nahi karte — bounded buffer gracefully parent note ke unbounded producer-consumer queue mein degrade ho jaata hai. Correct hai, bas koi back-pressure nahi.

Safe hai — kyunki predicate hamesha mutex held hone par evaluate hota hai. wait(lk, pred) pred() sirf tab call karta hai jab lk m own karta hai. Har writer (q.push, done = true) bhi m hold karta hai. Isliye q aur done ke saare reads aur writes usi mutex se serialize hote hain: predicate ek consistent snapshot dekhta hai. Us shared mutex ke bina tumhare paas data race hota aur tumhe uski jagah std::atomic aur careful memory ordering chahiye hota.

wait_for(lk, dur, pred) pred() ki value return karta hai jaise wait khatam hone ke baad evaluate ki gayi. Toh:

• true return kare ⇒ predicate satisfied hai (aage badho).
• false return kare ⇒ timeout elapsed ho gaya aur predicate abhi bhi false hai (timeout handle karo).

Predicate overload use karte waqt tumhe alag cv_status check ki zaroorat nahi — returned bool already batata hai tum kaun se case mein ho.

(a) 5 s mein available cycles $=2\times 10^9\times 5=1.0\times 10^{10}$ cycles. 4 cycles/iteration par: $\frac{1.0\times 10^{10}}{4}=2.5\times 10^9\text{ wasted iterations.}$ Yeh ~2.5 billion pointless loop turns hain jo ek full core jala rahe hain. (b) Condition_variable wait thread ko so deta hai (OS use de-schedule karta hai), isliye woh 5 seconds mein ~0 CPU lagti hai aur core real kaam ke liye free ho jaata hai — including, crucially, woh producer jo item create karne ke liye run karna chahiye. Yahi reason hai ki condition_variable exist karta hai.

Ek condition_variable bina memory ka ek doorbell hai. Tum ise hamesha ek shared flag aur ek mutex ke saath pair karte ho; waiter unique_lock ke zariye unlock-and-sleep karta hai, flag ko while loop mein dobara check karta hai (spurious/stolen wakeups), aur notifier flag ko lock ke under change karta hai phir bajata hai. Two-sided flow (bounded buffer) ko do bells chahiye; edge cases (N=0, bada N) deadlock aur unbounded hain; aur har predicate variable mutex ke under rehta hai ya atomic hai.