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

std::lock_guard<std::mutex>. It is the minimal RAII lock: locks in its constructor, unlocks in its destructor, and offers no other operations. "Simplest tool that fits" → lock_guard.

std::unique_lock<std::mutex> is required. std::condition_variable::wait must unlock while sleeping and re-lock on wakeup; only unique_lock exposes unlock()/lock(). lock_guard cannot unlock before its destructor, so it cannot participate.

• t.join() — block the current thread until t finishes, then release its resources.
• t.detach() — let t run on its own; you give up the ability to wait for it, and it cleans itself up when done. Exactly one must be called on a joinable thread before destruction.

int counter = 0;
std::mutex mtx;
void add(int N) {
    for (int i = 0; i < N; ++i) {
        std::lock_guard<std::mutex> lk(mtx); // lock this iteration
        ++counter;                           // read-modify-write, now serialized
    }                                        // lk destroyed -> unlock
}

Two threads, each doing N increments, with every ++counter inside a mutex → no lost updates. 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 is one shared object; without the lock two threads' characters interleave. The lock covers the whole (short) scope and never unlocks early → lock_guard is the correct, cheapest choice.

std::thread is move-only — it owns one unique OS thread, so copying is deleted. push_back(t) tries to copy → compile error. Fix: move it.

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

See Move semantics for why a move leaves t in a valid but resource-less state.

++counter = read counter into a register → increment the register → write back. Interleaving that loses an update (start counter = 41):

Both threads incremented, but the final value is 42, not 43 — one increment is lost. This unsynchronized shared write is a data race → Undefined behavior in C++.

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

lock_guard cannot unlock before scope end, so it would hold the lock through all of heavy — blocking others for no reason. unique_lock can unlock() early, so it is mandatory here. Use the flexible tool only when you use the flexibility.

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

• Thread 1 locks a, wants b.
• Thread 2 locks b, wants a.
• Each holds what the other needs → circular wait = deadlock. Neither ever proceeds.

It is a timing bug because it only triggers when both threads grab their first lock before either grabs its second. If thread 1 finishes entirely before thread 2 starts, no deadlock — the program "works" and hides the bug. That intermittency is exactly what makes lock-ordering bugs dangerous. See Deadlock and lock ordering.

void transfer(Account& a, Account& b, int amt) {
    std::unique_lock<std::mutex> la(a.m, std::defer_lock); // construct, DON'T lock
    std::unique_lock<std::mutex> lb(b.m, std::defer_lock);
    std::lock(la, lb);   // lock BOTH atomically, deadlock-free
    a.bal -= amt;
    b.bal += amt;
} // both released by RAII

std::defer_lock makes each unique_lock adopt but not lock its mutex. std::lock(la, lb) uses a back-off algorithm: it tries to grab all, and if it can't get one it releases any it holds and retries, so no thread sits holding one mutex while waiting for another → the circular-wait condition is broken. (C++17: std::scoped_lock lk(a.m, b.m); does the same in one line.)

std::mutex m;
std::condition_variable cv;
std::queue<int> q;
 
int consume() {
    std::unique_lock<std::mutex> lk(m);          // unique_lock: cv needs unlock/relock
    cv.wait(lk, []{ return !q.empty(); });       // predicate guards spurious wakeups
    int v = q.front(); q.pop();
    return v;
} // lk released

• unique_lock because cv.wait unlocks lk while sleeping and re-locks on wakeup — lock_guard can't.
• Predicate form wait(lk, pred) re-checks !q.empty() on every wakeup, so a spurious wakeup (OS wakes the thread with no real notify) doesn't pop an empty queue. See std::condition_variable.

Both give the correct final value $=8\times 1,000,000=8000000$.

• (a) mutex: every ++counter pays lock + unlock (kernel-mediated contention when threads collide). Correct but heavy for a one-instruction critical section.
• (b) std::atomic<long>: counter.fetch_add(1) (or ++counter) is a single lock-free hardware instruction; no blocking, no OS involvement. For a pure counter, std::atomic is faster — mutexes shine when the critical section is more than one trivial op. See std::atomic and lock-free programming.

template <class T>
class Guarded {
    T data;
    std::mutex m;
public:
    template <class F>
    auto with(F&& f) {                       // the ONLY way to reach data
        std::lock_guard<std::mutex> lk(m);   // lock for the whole call
        return f(data);                      // hand a reference to the callback
    }                                        // auto-unlock
};
// usage: g.with([](int& x){ ++x; });

data is private; the only path to it is with, which locks first. There is no API to get a raw reference that outlives the lock, so "use without locking" won't compile. This is RAII and resource management pushed to its limit: the type system enforces the locking discipline.

Use std::async/std::future when a thread's job is to compute and return a value. future::get() transfers the result out with no shared mutable state and no manual mutex — you get the value and any exception, synchronized for you. This removes an entire class of data-race bugs. Here f.get() returns $6\times 7=42$. See std::async and std::future.

L1 name the tool ::: lock_guard simple, unique_lock flexible, join/detach on threads. L2 write it ::: guard the read-modify-write; threads are move-only. L3 analyze it ::: ++ is read-inc-write; naive two-lock ordering deadlocks by timing. L4 synthesize ::: std::lock(defer,defer) beats deadlock; unique_lock+cv for waiting. L5 master ::: atomic for counters, future for results, Guarded<T> makes locking mandatory.