Exercises — Concurrency — std - thread, std - mutex, std - lock_guard, std - unique_lock

std::lock_guard<std::mutex>. Yeh minimal RAII lock hai: apne constructor mein lock karta hai, destructor mein unlock karta hai, aur koi doosra operation nahi deta. "Sabse simple tool jo fit ho" → lock_guard.

std::unique_lock<std::mutex> zaroori hai. std::condition_variable::wait ko sote waqt unlock aur wakeup pe re-lock karna hota hai; sirf unique_lock hi unlock()/lock() expose karta hai. lock_guard apne destructor se pehle unlock nahi kar sakta, isliye woh participate nahi kar sakta.

• t.join() — current thread ko block karo jab tak t khatam na ho jaye, phir uske resources release karo.
• t.detach() — t ko apne aap chhalne do; tum uska wait karne ki ability kho dete ho, aur woh khatam hone pe khud clean up kar leta hai. Destruction se pehle ek joinable thread pe exactly ek call karni hi hogi.

int counter = 0;
std::mutex mtx;
void add(int N) {
    for (int i = 0; i < N; ++i) {
        std::lock_guard<std::mutex> lk(mtx); // is iteration ko lock karo
        ++counter;                           // read-modify-write, ab serialized hai
    }                                        // lk destroy hoga -> unlock
}

Do threads, har ek N increments karte hue, har ++counter mutex ke andar → koi lost updates nahi. Guaranteed final value $=2N=2\times 500000=1000000$.

std::mutex io_mtx;
void say(const std::string& s) {
    std::lock_guard<std::mutex> lk(io_mtx);
    std::cout << s << "\n";
}

std::cout ek shared object hai; lock ke bina do threads ke characters interleave ho jaate hain. Lock poore (chote) scope ko cover karta hai aur kabhi early unlock nahi karta → lock_guard sahi, sabse sasta choice hai.

std::thread move-only hai — woh ek unique OS thread own karta hai, isliye copying delete hai. push_back(t) copy karne ki koshish karta hai → compile error. Fix: ise move karo.

pool.push_back(std::move(t)); // ownership transfer; t ab empty (non-joinable) hai

Move semantics dekho ki kyun ek move t ko valid lekin resource-less state mein chhod deta hai.

++counter = ek register mein counter read karo → register increment karo → write back karo. Woh interleaving jo ek update lose karta hai (start counter = 41):

Dono threads ne increment kiya, lekin final value 42, 43 nahi hai — ek increment lost ho gaya. Yeh unsynchronized shared write ek data race hai → Undefined behavior in C++.

std::mutex mtx;
void worker() {
    std::unique_lock<std::mutex> lk(mtx); // locked
    int x = read_shared();                // lock ke under shared read
    lk.unlock();                          // EARLY release
    heavy(x);                             // koi shared state nahi -> koi lock nahi chahiye
}

lock_guard scope end se pehle unlock nahi kar sakta, isliye woh heavy ke poore time lock hold karega — bina kisi wajah ke doosron ko block karta hua. unique_lock unlock() early kar sakta hai, isliye yeh mandatory hai. Flexible tool ko sirf tabhi use karo jab tum flexibility use kar rahe ho.

Naive body: lock(a.m); lock(b.m); .... Phir:

• Thread 1 a lock karta hai, b chahta hai.
• Thread 2 b lock karta hai, a chahta hai.
• Har ek woh hold karta hai jo doosre ko chahiye → circular wait = deadlock. Koi aage nahi badhta.

Yeh ek timing bug hai kyunki yeh tabhi trigger hota hai jab dono threads apna pehla lock grab kar lein kisi ke bhi doosra grab karne se pehle. Agar thread 1 poori tarah khatam ho jaye thread 2 ke shuru hone se pehle, koi deadlock nahi — program "kaam karta hai" aur bug chhup jaata hai. Yahi intermittency hai jo lock-ordering bugs ko dangerous banati hai. Deadlock and lock ordering dekho.

void transfer(Account& a, Account& b, int amt) {
    std::unique_lock<std::mutex> la(a.m, std::defer_lock); // construct, lock MAT karo
    std::unique_lock<std::mutex> lb(b.m, std::defer_lock);
    std::lock(la, lb);   // DONO ko atomically lock karo, deadlock-free
    a.bal -= amt;
    b.bal += amt;
} // dono RAII se release ho jaate hain

std::defer_lock har unique_lock ko adopt karta hai lekin lock nahi karta apna mutex. std::lock(la, lb) ek back-off algorithm use karta hai: woh sab grab karne ki koshish karta hai, aur agar ek nahi mila toh jo bhi hold kar raha hai use release karke retry karta hai, isliye koi thread ek mutex hold karte hue doosre ka wait nahi karta → circular-wait condition toot jaati hai. (C++17: std::scoped_lock lk(a.m, b.m); ek line mein yahi karta hai.)

std::mutex m;
std::condition_variable cv;
std::queue<int> q;
 
int consume() {
    std::unique_lock<std::mutex> lk(m);          // unique_lock: cv ko unlock/relock chahiye
    cv.wait(lk, []{ return !q.empty(); });       // predicate spurious wakeups se bachata hai
    int v = q.front(); q.pop();
    return v;
} // lk release ho jaata hai

• unique_lock isliye kyunki cv.wait sote waqt lk unlock karta hai aur wakeup pe re-lock karta hai — lock_guard nahi kar sakta.
• Predicate form wait(lk, pred) har wakeup pe !q.empty() dobara check karta hai, taaki ek spurious wakeup (OS bina real notify ke thread jagata hai) empty queue ko pop na kare. std::condition_variable dekho.

Dono sahi final value dete hain $=8\times 1,000,000=8000000$.

• (a) mutex: har ++counter lock + unlock pay karta hai (threads collide hone par kernel-mediated contention). Sahi hai lekin ek one-instruction critical section ke liye heavy hai.
• (b) std::atomic<long>: counter.fetch_add(1) (ya ++counter) ek single lock-free hardware instruction hai; koi blocking nahi, koi OS involvement nahi. Ek pure counter ke liye, std::atomic faster hai — mutexes tab shine karte hain jab critical section ek trivial op se zyada ho. std::atomic and lock-free programming dekho.

template <class T>
class Guarded {
    T data;
    std::mutex m;
public:
    template <class F>
    auto with(F&& f) {                       // data tak pahunchne ka AKEELA rasta
        std::lock_guard<std::mutex> lk(m);   // poori call ke liye lock
        return f(data);                      // callback ko reference do
    }                                        // auto-unlock
};
// usage: g.with([](int& x){ ++x; });

data private hai; uska ekeela rasta with hai, jo pehle lock karta hai. Koi API nahi jo ek raw reference de jo lock se zyada jiye, isliye "bina locking ke use karna" compile hi nahi hoga. Yeh RAII and resource management hai apni limit tak push kiya: type system locking discipline enforce karta hai.

std::async/std::future tab use karo jab thread ka kaam ek value compute karke return karna ho. future::get() result bina kisi shared mutable state aur bina manual mutex ke transfer karta hai — tumhe value aur koi bhi exception milti hai, tumhare liye synchronized. Yeh data-race bugs ki ek poori class hata deta hai. Yahan f.get() $6\times 7=42$ return karta hai. std::async and std::future dekho.

L1 tool ka naam ::: lock_guard simple, unique_lock flexible, threads pe join/detach. L2 likho ::: read-modify-write guard karo; threads move-only hain. L3 analyze karo ::: ++ read-inc-write hai; naive two-lock ordering timing se deadlock karta hai. L4 synthesize karo ::: std::lock(defer,defer) deadlock ko harata hai; wait karne ke liye unique_lock+cv. L5 master karo ::: counters ke liye atomic, results ke liye future, Guarded<T> locking mandatory banata hai.