The Concurrency API

Chapter 1: Launch Policies

std::async doesn't always run your function asynchronously. Its default launch policy is std::launch::async | std::launch::deferred, which means: "run it however you want."

The infinite loop trap

c++
auto fut = std::async(f);  // default policy

while (fut.wait_for(100ms) != std::future_status::ready) {
    ...  // If f is deferred, this loops FOREVER!
         // wait_for always returns future_status::deferred
}

The fix

c++
auto fut = std::async(f);

if (fut.wait_for(0s) == std::future_status::deferred) {
    fut.get();  // call synchronously
} else {
    while (fut.wait_for(100ms) != std::future_status::ready) {
        ...  // safe: task is not deferred
    }
}

Chapter 2: Make std::threads Unjoinable on All Paths

Every std::thread is either joinable (corresponds to a running/runnable thread) or unjoinable (default-constructed, moved-from, joined, or detached). If a joinable thread's destructor runs, your program is terminated.

ThreadRAII: an RAII wrapper

c++
class ThreadRAII {
public:
    enum class DtorAction { join, detach };

    ThreadRAII(std::thread&& t, DtorAction a)
        : action(a), t(std::move(t)) {}

    ~ThreadRAII() {
        if (t.joinable()) {
            if (action == DtorAction::join) t.join();
            else t.detach();
        }
    }

    ThreadRAII(ThreadRAII&&) = default;
    ThreadRAII& operator=(ThreadRAII&&) = default;

    std::thread& get() { return t; }
private:
    DtorAction action;
    std::thread t;  // declared last: initialized last (after all other members)
};

Why both join and detach were rejected as defaults

Using ThreadRAII

c++
bool doWork(std::function<bool(int)> filter, int maxVal) {
    std::vector<int> goodVals;

    ThreadRAII t(
        std::thread([&filter, maxVal, &goodVals] {
            for (auto i = 0; i <= maxVal; ++i)
                if (filter(i)) goodVals.push_back(i);
        }),
        ThreadRAII::DtorAction::join  // join if exception or early return
    );

    auto nh = t.get().native_handle();
    // ... set priority via platform API ...

    if (conditionsAreSatisfied()) {
        t.get().join();
        performComputation(goodVals);
        return true;
    }
    return false;  // ThreadRAII destructor joins the thread safely
}

Chapter 3: Future Destructor Behavior

Unlike std::thread, futures don't terminate your program when destroyed. But their destructor behavior is surprisingly nuanced.

The shared state

Results from async tasks live in a shared state — a heap-allocated object accessible to both the caller's future and the callee's std::promise:

Destructor rules

std::packaged_task avoids blocking

c++
// This future's dtor will NOT block
std::packaged_task<int()> pt(calcValue);
auto fut = pt.get_future();  // shared state NOT from std::async
std::thread t(std::move(pt));
// You must join or detach t yourself

Chapter 4: Void Futures for One-Shot Events

You have a detecting task that needs to signal a reacting task. What's the best mechanism?

c++
std::promise<void> p;

// Detecting task:
...                       // detect event
p.set_value();              // signal!

// Reacting task:
...                       // prepare
p.get_future().wait();    // block until signaled
...                       // react

Suspending threads at creation

c++
std::promise<void> p;

void detect() {
    std::thread t([] {
        p.get_future().wait();   // suspend until signaled
        react();
    });
    ...                         // configure t (priority, affinity, etc.)
    p.set_value();               // unsuspend t
    ...
    t.join();
}

Multiple reacting tasks: use shared_future

c++
std::promise<void> p;
auto sf = p.get_future().share();

std::vector<std::thread> threads;
for (int i = 0; i < n; ++i)
    threads.emplace_back([sf]{ sf.wait(); react(); });

p.set_value();  // wake all threads simultaneously

for (auto& t : threads) t.join();

Chapter 5: std::atomic vs volatile

std::atomic and volatile serve completely different purposes. Confusing them is a common and dangerous mistake.

Atomic guarantees atomicity and ordering

c++
std::atomic<int> ai(0);
ai = 10;      // atomically set to 10
++ai;         // atomic read-modify-write → 11
--ai;         // atomic RMW → 10
// Other threads see only 0, 10, or 11. Never a torn value.

// Sequential consistency: no reordering past atomic writes
auto val = computeValue();    // (1)
std::atomic<bool> ready(false);
ready = true;                  // (2) guaranteed after (1)

volatile prevents optimization of special memory

c++
volatile int x;

auto y = x;  // read x (preserved — might be sensor data)
y = x;       // read x again (preserved — value might have changed!)

x = 10;      // write x (preserved — might be a hardware command)
x = 20;      // write x (preserved — might be a different command)

// Without volatile, compiler would optimize to: auto y = x; x = 20;

Code reordering: the critical difference

c++
// With std::atomic: guaranteed ordering
auto imptValue = computeImportantValue();  // (1)
std::atomic<bool> valAvailable(false);
valAvailable = true;                        // (2) — (1) guaranteed before (2)
// Other threads see imptValue BEFORE valAvailable becomes true

// With volatile: NO ordering guarantee
auto imptValue = computeImportantValue();  // might be reordered!
volatile bool valAvailable = false;
valAvailable = true;                        // might execute BEFORE imptValue!
// Other threads could see valAvailable = true but imptValue not yet computed

Why std::atomic isn't copyable

c++
std::atomic<int> x;
auto y = x;       // ERROR! Copy operations are deleted.
// Reading x and writing y atomically as ONE operation
// is impossible on most hardware.

// Use load() and store() instead:
std::atomic<int> y(x.load());  // atomic read, then init y
y.store(x.load());               // atomic read, then atomic write
// Each operation is atomic, but the pair is NOT atomic together

Chapter 6: The Thread Model

Understanding the three layers of threads helps you reason about concurrency.

Chapter 7: Event Communication Patterns

Click each pattern to see its trade-offs.

Chapter 8: Atomic vs Volatile Visualized

See how std::atomic and volatile handle concurrent increments differently.

Chapter 9: Beyond

"For the first time in C++'s history, programmers can write multithreaded programs with standard behavior across all platforms." — Scott Meyers