Foundations — std - promise and std - future

5.2.28 · D1 · Coding › C++ Programming › std - promise and std - future

Parent note padhne se pehle, tumhe us par tike har word ka maalik banana hoga. Yeh page har ek ko zero se build karta hai — pehle simple words, phir ek picture, phir kyun topic ko uski zaroorat hai. Upar se neeche padho; har item agले ke liye ek brick hai. Upar bataaye gaye do named ends abhi sirf labels hain; sections 3–6 box ke andar ki machinery build karte hain, aur section 7 ends ko precisely define karta hai.

1. Thread — "ek worker jo ek saath run karta hai"

Do runners ko parallel tracks par imagine karo. Wo saath shuru karte hain, apni apni pace se daudte hain, aur koi doosre ka wait nahi karta jab tak tum unhe batao nahi.

Figure 1 — do arrows do threads hain (teal = main, orange = worker); plum dots mark karte hain ki dono ek hi moment par shuru hote hain aur phir apne apne track par independently aage badhte hain.

Topic ko yeh kyun chahiye: promise/future exist sirf isliye karta hai kyunki ek se zyada thread run ho raha hai. Agar ek thread hota, tum sirf ek function call karte aur uska return value padhte — koi mailbox ki zaroorat nahi. std::thread dekho.

2. Shared data + data race — "ek object par do haath"

Do logon ko ek saath ek kagaz par likhte imagine karo: akshar nonsense mein overlap ho jaate hain.

3. Mutex + lock_guard + unique_lock — "talking stick"

Ek talking stick imagine karo: sirf woh insaan jo ise hold karta hai bol sakta hai; baki sab wait karte hain.

std::mutex m;                          // the lock object itself
int shared_value;                      // the thing we protect
 
{
    std::lock_guard<std::mutex> lk(m); // lock m here (lk "guards" m)
    shared_value = 42;                 // safe: we hold the stick
}                                      // lk destroyed -> unlock automatically

Topic ko yeh kyun chahiye: shared state ka flag aur value ek thread dwara write kiya jaata hai aur doosre dwara padha jaata hai — ek mutex un touches ko serialise karta hai taaki koi data race na ho, aur unique_lock exactly woh tool hai jo waiting step ko chahiye. std::mutex and lock_guard dekho.

4. Ready flag — "kya box fill ho gaya hai?"

Ek mailbox ko ek choti red flag ke saath imagine karo: postman ise uthata hai jab letter andar hota hai, taaki tum jaano bahar jaake collect karo.

Topic ko yeh kyun chahiye: iske bina, waiter ek empty box aur ek box mein legitimately-zero value ke beech farq nahi bata sakta. Flag "data present" bit hai — aur yeh woh condition hai jis par agla tool (condition variable) wait karta hai.

5. Condition variable — "poke hone tak so jao"

Kisi ko note ke saath so hue imagine karo: "mujhe tab jagao jab kettle boil ho." Wo wait karte hue koi energy burn nahi karte; jo kettle boil karta hai woh unke kandhe ko tap karta hai — woh tap notify_one hai.

Figure 2 — teal box sleeping waiter hai jo ek unique_lock hold kar raha hai; orange box setter hai jo abhi value store kar chuka hai aur ready flip kar chuka hai; plum arrow woh notify_one() call hai jo waiter ko jagaata hai. Upar ke busy-wait note se compare karo: woh teal box ko 100% CPU par spin karta instead of soye rehne dene ke.

Alternative — ek busy-wait loop while(!ready) {} (section 4 ke ready flag ka use karke) — CPU ko 100% par kuch nahi karte hue spin karta hai. Condition variable efficient sleep hai.

Yahan canonical wait loop hai jo setter aur waiter perform karte hain, shared state se m, ready, aur cv ka use karke:

std::mutex m;
std::condition_variable cv;
bool ready = false;
int value;
 
// --- SETTER (producer thread) ---
{
    std::lock_guard<std::mutex> lk(m); // 1. lock the mutex
    value = 42;                        // 2. store the value
    ready = true;                      // 3. flip the ready flag
}                                      // 4. unlock (lk destroyed)
cv.notify_one();                       // 5. wake the waiter (outside the lock)
 
// --- WAITER (consumer thread) ---
{
    std::unique_lock<std::mutex> lk(m);        // unique_lock, NOT lock_guard
    cv.wait(lk, []{ return ready; });          // sleeps; releases m while asleep,
                                               // re-checks ready on every wake
    int got = value;                           // safe: we hold m and ready==true
}

6. Shared state — "woh mailbox jisme teeno rehte hain"

Ek physical mailbox ko do keys ke saath imagine karo — writer ki key aur reader ki key — lekin sirf ek box.

Figure 3 — central boxed block shared state hai; andar sections 3–5 ke chaar members hain (value-or-exception, ready flag, mutex, condition variable). Orange arrow promise hai andar likhte hue; teal arrow future hai bahar padhte hue. Dono arrows same box ki taraf point karte hain — yahi "shared" ka matlab hai.

Topic ko yeh kyun chahiye: yeh literally woh "ek cheez hai jise wo milke manage karte hain" hai jo parent note name karta hai. Promise = writing end, future = reading end, shared state = unke beech ka box.

7. Promise aur future — "box ke do ends"

Mailbox ko phir se imagine karo: promise woh slot hai street par jahan postman letter daalta hai; future woh choti door hai tumhari wall ki side par jahan tum ise collect karte ho.

8. Exceptions aur exception_ptr — "box mein ek error ship karna"

Topic ko yeh kyun chahiye: yeh set_exception / get() mein re-throw hai — parent ka Worked Example 2.

9. Move semantics aur std::move — "clone nahi, hand over karo"

Figure 4 — top row: ek promise ko copy karna (dashed clone, red mein struck through) do writing ends bana deta jo same box ko aim karte, isliye do threads dono set_value call kar sakte — language ise forbid karta hai. Bottom row: std::move single shared state ko purane promise (ab empty, dotted outline) se naye mein (solid) transfer karta hai — abhi bhi exactly ek owner. Picture yahi rule hai: ek box, ek writer.

Topic ko yeh kyun chahiye: std::thread t(worker, std::move(prom)); — tum promise worker ko hand karte ho; ise clone karna woh error hoga jo language allow karne se refuse karta hai. Move semantics and std::move dekho.

10. One-shot semantics — "letter padho, phir gone"

Ek sealed envelope kholne ko imagine karo: ek baar kholne aur letter nikalne ke baad, dobara kholne ke liye kuch nahi bacha. Ek doosra get() future_error throw karta hai code no_state ke saath.

Topic ko yeh kyun chahiye: yeh explain karta hai kyun get() future ko invalidate karta hai, kyun valid() false ho jaata hai, aur kyun multiple readers ko std::shared_future chahiye.

Yeh bricks topic kaise build karte hain

Related building blocks jo aage milenge

Jab yeh foundations solid ho jayein, parent topic bahar higher-level tools se connect hota hai jo same machinery wrap karte hain: std::async and std::launch (jo tumhe automatically future deta hai), std::packaged_task (jo ek callable ke return ko ek promise mein wrap karta hai), aur std::shared_future (ek result ke kai readers).

Equipment checklist

Khud ko test karo — parent note padhne se pehle tum in mein se har ek answer de sakna chahiye.