Exercises — std - promise and std - future

• Writing end (producer): std::promise<T> — tum is par set_value / set_exception call karte ho. (Yeh page ke top-of-page figure mein left side wala pen hai.)
• Reading end (consumer): std::future<T> — tum is par get() / wait() call karte ho. (Yeh us figure mein right side wali key hai.)

Dono ek hi shared state box ki taraf point karte hain. Mnemonic: ek promise woh hoti hai jo tum karte ho (likhte ho); ek future woh hoti hai jiska tum intezaar karte ho (padhte ho).

std::future<int> f = p.get_future();

get_future() tumhe usi shared state box ki reading key deta hai (top-of-page figure mein dashed white arrow). Isse exactly ek baar call karo — doosri call std::future_error throw karegi, kyunki ek single writer ek box ke liye do independent reading ends distribute nahi kar sakta.

Producer (promise) ::: set_value, set_exception, get_future Consumer (future) ::: get, wait

(get_future promise par rehta hai lekin consumer object produce karta hai.)

void worker(std::promise<int> p) {
    int r = 9 * 9;
    p.set_value(r);   // box mein 81 store karo, ready mark karo, waiter ko jagao
}

Yeh top-of-page figure mein pen ka box mein likhna hai. Doosri side par fut.get() phir 81 return karega.

Chaar lines ka sahi order: B, C, A, D (saath mein pehle se diya t.join(); D ke baad aata hai).

std::promise<int> prom;                 // B: promise banao (box create hota hai)
std::future<int> fut = prom.get_future();// C: move se pehle reading key lo
std::thread t(worker, std::move(prom)); // A: move-only, promise thread ko do
int x = fut.get();                      // D: set_value hone tak block karo -> value
t.join();                               // (diya hua, A–D mein se nahi)

C pehle A se kyun: std::move(prom) promise ki box ki ownership thread mein transfer kar deta hai; local prom khaali reh jaata hai (koi shared state nahi). Agar tum phir prom.get_future() call karo, toh key dene ke liye koi box hi nahi hai, isliye future_error(no_state) throw hoga. Move se pehle key lene se woh tab capture hoti hai jab local promise abhi bhi box ko own karti hai. Line D top-of-page figure mein key ka box se padhna hai.

fut.get() broken_promise error code ke saath std::future_error throw karega. Lambda ne promise ko move se capture kiya aur use set_value/set_exception ke bina destroy ho jaane diya. Promise ka destructor, yeh dekh kar ki box kabhi fill nahi hua, box ko ready mark karta hai lekin broken_promise error ke saath, phir waiters ko jagata hai — isliye wait kar raha get() koi value deliver nahi kar sakta aur hamesha ke liye hang hone ki jagah re-throw karta hai.

Fix: har path par promise set karo — jaise lambda ke andar p.set_value(0);.

get() stored value ko move out karta hai (dekho Move semantics and std::move): return hone ke baad, box is future ke liye ek value hold nahi karta, aur fut.valid() false ho jaata hai. Isliye doosri get() kuch return nahi kar sakti aur std::future_error(no_state) throw karti hai. Multiple consumers ke liye, std::shared_future use karo (dekho std::shared_future): iska get() ek const reference return karta hai (move out ki jagah copy out karta hai), isliye isе kai copies dwara baar baar call kiya ja sakta hai.

Pehle, lk kya hai? Yeh lock object hai jo mutex hold karta hai:

std::unique_lock<std::mutex> lk(m);   // lk mutex m par lock own karta hai
cv.wait(lk, []{ return ready; });     // cv atomically lk ko sleeping mein release karta hai,
                                      // wake par re-acquire karta hai, phir ready check karta hai

cv.wait ko unique_lock chahiye (lock_guard nahi) exactly isliye kyunki jab thread sota hai tab use mutex unlock karna hota hai aur wake par re-lock karna hota hai — dekho std::mutex and lock_guard.

Predicate jo do problems solve karta hai (dono std::condition_variable se):

1. Spurious wakeups — ek condition_variable bina kisi notify ke wait se return kar sakta hai. Predicate ready ko dobara check karta hai aur agar woh abhi bhi false hai toh wapis so jaata hai.
2. Lost wakeup / set-before-wait race — agar set_value reader ke wait tak pahunchne se pehle run ho, toh ready already true hai, isliye predicate form immediately return karta hai instead of hamesha ke liye block hone ke, aisa wait karte hue jo already fire ho chuka notify ka.

Plain cv.wait(lk) dono mein se koi bhi handle nahi karta.

(A) get_future() ke baad ::: true — ek shared state ke saath associated hai (B) set_value ke baad ::: true — value stored hai, lekin future abhi consume nahi hua (C) get() ke baad ::: false — value move out ho gayi, future invalidate ho gaya

Toh sequence hai true, true, false. Value set karna future ko invalidate nahi karta; sirf use consume karna karta hai.

#include <future>
#include <thread>
#include <iostream>
 
void worker(std::promise<int> p) {
    p.set_value(123);           // ek call storage + notify dono package karta hai
}
 
int main() {
    std::promise<int> prom;
    std::future<int>  fut = prom.get_future();
    std::thread t(worker, std::move(prom));
    std::cout << fut.get() << "\n";   // -> 123
    t.join();
}

Single promise/future pair mutex, std::condition_variable, ready flag, aur shared variable — sab shared state ke andar sahi tarike se bundle hoke — replace kar deta hai.

void worker(std::promise<int> p) {
    try {
        throw std::out_of_range("bad index");
    } catch (...) {
        p.set_exception(std::current_exception());  // capture & ship
    }
}
 
int main() {
    std::promise<int> prom;
    auto fut = prom.get_future();
    std::thread t(worker, std::move(prom));
    try {
        int x = fut.get();          // yahan re-throw hota hai, IS thread mein
        std::cout << x;
    } catch (const std::exception& e) {
        std::cout << "caught: " << e.what() << "\n"; // -> caught: bad index
    }
    t.join();
}

Dekho Exception handling in C++. Iske bina, thread function se escape hoti exception std::terminate call karti hai.

#include <future>
#include <iostream>
 
int main() {
    std::future<int> fut = std::async(std::launch::async,
                                      []{ return 123; });
    std::cout << fut.get() << "\n";   // -> 123
}

std::async internally promise/shared-state create karta hai, callable run karta hai, tumhare liye value (ya exception) set karta hai, aur future wapis deta hai.

Destructor nuance ke baare mein savdhani: std::async dwara return kiya gaya future special hota hai — jab woh destroy hota hai tab woh task finish hone tak block karega, lekin sirf tab jab task std::launch::async ke saath launch hua ho aur abhi bhi run ho raha ho. std::launch::deferred ke saath callable shuru nahi hua hota, aur deferred task sirf tab run hota hai jab tum explicitly get() ya wait() call karo — future ka destructor use run nahi karta; agar tum kabhi get()/wait() call nahi karte, toh callable simply kabhi execute nahi hota. Agar tum launch policy omit karo (std::async(f)), toh implementation koi bhi policy choose kar sakti hai, isliye tum na blocking na deferred behaviour par rely kar sakte ho. Sirf std::launch::async "join on destruction" behaviour guarantee karta hai jaise upar use kiya gaya. (Plain std::promise se obtained futures destruction par block nahi karte.)

Members aur unke kaam (yeh exactly wahi box hai jo page ke top par draw kiya gaya hai):

1. T value — successful result ke liye storage (figure mein "value" inner slot).
2. std::exception_ptr ex — ek alternative slot taaki ek throw ki gayi exception value ki jagah ship ki ja sake.
3. bool ready = false — reader-facing flag: "kya box fill ho gaya?" Consumer ka cv.wait tab tak sota rehta hai jab tak yeh true nahi ho jaata ("ready" inner slot).
4. bool written = false — write-once enforcement ke liye writer-facing guard: "kya kisi producer ne already set_value/set_exception call kar li?" Hume ise ready se alag chahiye kyunki ek set_* call ko doosri write attempt detect karni hoti hai (aur throw karna hota hai) — ready akela "filled, padhne ka wait" aur "koi doosri baar likhne ki koshish kar raha hai" ke beech distinguish nahi kar sakta. Real std::promise mein yahi guard promise_already_satisfied raise karta hai.
5. std::mutex m — value/ex/ready/written ko threads ke across data race se protect karta hai ("mutex" inner slot).
6. std::condition_variable cv — reader ko busy-spin karne ki jagah sleep karne aur jagaye jaane deta hai ("condition_variable" inner slot).

#include <mutex>
#include <condition_variable>
#include <exception>
#include <memory>
#include <stdexcept>
 
template<class T>
struct State {
    std::mutex m;
    std::condition_variable cv;
    bool ready = false;     // reader flag: kya box fill ho gaya?
    bool written = false;   // writer guard: kya koi bhi set_* already hua?
    T value{};
    std::exception_ptr ex;
};
 
template<class T> struct MiniFuture;   // forward declaration
 
template<class T>
struct MiniPromise {
    std::shared_ptr<State<T>> s = std::make_shared<State<T>>();
 
    MiniFuture<T> get_future();         // neeche define hua, MiniFuture ke baad
 
    void set_value(T v) {
        {   std::lock_guard<std::mutex> lk(s->m);
            if (s->written) throw std::logic_error("already satisfied");
            s->value = std::move(v);
            s->written = true;          // write-once guard
            s->ready   = true;          // reader ko jagao
        }
        s->cv.notify_all();
    }
 
    void set_exception(std::exception_ptr e) {
        {   std::lock_guard<std::mutex> lk(s->m);
            if (s->written) throw std::logic_error("already satisfied");
            s->ex      = e;
            s->written = true;
            s->ready   = true;
        }
        s->cv.notify_all();
    }
};
 
template<class T>
struct MiniFuture {
    std::shared_ptr<State<T>> s;
 
    T get() {
        std::unique_lock<std::mutex> lk(s->m);   // unique_lock: wait ise unlock kar sakta hai
        s->cv.wait(lk, [&]{ return s->ready; }); // fill hone tak so jao
        if (s->ex) std::rethrow_exception(s->ex);// exception transport
        return std::move(s->value);              // value move out karo
    }
};
 
// ab MiniFuture complete hai, isliye get_future() define kar sakte hain:
template<class T>
MiniFuture<T> MiniPromise<T>::get_future() {
    return MiniFuture<T>{ s };   // usi shared state ko future ko do
}

Dono flags alag kaam karte hain: written producer side par write-once enforce karta hai (doosre set_* par throw karta hai), jabki ready woh predicate hai jis par consumer wait karta hai. ex slot exception transport provide karta hai, aur get_future() simply shared_ptr copy karta hai taaki promise aur future ek State ko co-own karein — yahi kaam real std::promise/std::future karta hai.

std::vector<std::future<int>> futs;
futs.push_back(std::async(std::launch::async, []{ return 10; }));
futs.push_back(std::async(std::launch::async, []{ return 20; }));
futs.push_back(std::async(std::launch::async, []{ return 30; }));
 
int sum = 0;
for (auto& f : futs) sum += f.get();   // har get() APNE task ka wait karta hai
// sum == 60

Sum 60 hai. Har get() apne khud ke shared state ke liye independently wait karta hai, isliye tasks jo bhi order mein finish hote hain, loop simply har ek par block karta hai aur use add karta hai. Addition commutative hai, isliye total order-independent hai.

Promise aur future box ko co-own karte hain (ek shared control block ke zariye). Jab promise destroy hota hai, iska destructor check karta hai: "kya maine kabhi koi value/exception set ki?" Agar nahi, toh woh box mein ek broken_promise error store karta hai aur use ready mark karta hai — phir waiters ko jagata hai. Isliye wait kar raha get() ready == true dekhta hai, stored future_error(broken_promise) paata hai, aur ise re-throw karta hai. Key design choice: "promise destruction hamesha box resolve karta hai (value, exception, ya broken-promise error ke saath)", jo guarantee karta hai ki future kabhi aisi promise par wait nahi kar sakti jo kabhi jawab nahi degi — koi deadlock nahi.

• Writing end = promise, reading end = future; dono ek shared state box ki taraf point karte hain.
• get_future() std::move(prom) se pehle.
• Exactly ek write (set_value ya set_exception).
• Exactly ek read (get()), jo future ko invalidate karta hai.
• Unset-then-destroyed promise → get() par broken_promise.