{"title":"C++20 Concurrency Features","description":"","content":"C++20 solves this. `std::jthread` auto-joins on destruction and integrates with `std::stop_token` for cooperative cancellation. Combined with new synchronization primitives like `std::latch`, `std::barrier`, and `std::counting_semaphore`, C++20 brings the concurrency toolkit to a new level of expressiveness and safety.\n\nThis chapter covers these new primitives, but more importantly, it shows how they work together to solve real problems. By the end, you'll be able to rewrite common threading patterns with safer, more expressive code.\n\n## std::jthread: The Safe Thread\n\nEvery C++ developer has been bitten by `std::thread` at some point. Forget to call `join()` or `detach()`, and your program terminates. It's a simple mistake with catastrophic consequences, and it happens more often than anyone likes to admit.\n\n`std::jthread` (joining thread) fixes this by making the safe behavior the default. It's a drop-in replacement for `std::thread` that:\n\n1. Automatically joins in its destructor (no more terminate on forgotten join)\n2. Integrates with the stop token system for cooperative cancellation\n\nHere's what graceful shutdown looks like with `jthread`. Notice how the worker receives a `stop_token` as its first parameter, and checks it periodically.\n\n\n```cpp\n#include \n#include \n\nvoid worker(std::stop_token stoken) {\n while (!stoken.stop_requested()) {\n // Do work\n std::cout << \"Working...\\n\";\n std::this_thread::sleep_for(std::chrono::milliseconds(500));\n }\n std::cout << \"Worker stopping gracefully\\n\";\n}\n\nint main() {\n std::jthread t(worker); // Passes stop_token automatically\n\n std::this_thread::sleep_for(std::chrono::seconds(2));\n\n // jthread destructor requests stop and joins\n} // t.~jthread() calls request_stop() then join()\n```\n\n\nWhen `t` goes out of scope, its destructor first calls `request_stop()` to signal the worker, then `join()` to wait for it. No explicit cleanup code needed. No forgotten joins. No mysterious hangs.\n\nCompare this with the traditional approach using `std::thread`. The difference is stark: you need a manual stop flag, you must remember to set it, and you must remember to join.\n\n\n```cpp\n// std::thread - manual management required\nvoid old_way() {\n std::atomic stop_flag{false};\n\n std::thread t([&stop_flag] {\n while (!stop_flag) {\n // Do work\n }\n });\n\n // Must remember to signal and join\n stop_flag = true;\n t.join(); // Forgetting this terminates the program!\n}\n```\n\n\nThe diagram below illustrates this fundamental difference. With `std::thread`, forgetting any step leads to either a resource leak (detached thread running forever) or program termination. With `std::jthread`, safety is the default.\n\n\n```mermaid\nflowchart TB\n subgraph StdThread[\"std::thread\"]\n T1[\"Create thread\"]\n T2[\"Manual stop flag\"]\n T3[\"Manual join()\"]\n T4[\"Forget = terminate!\"]\n end\n\n subgraph JThread[\"std::jthread\"]\n J1[\"Create jthread\"]\n J2[\"Auto stop_token\"]\n J3[\"Auto join on destroy\"]\n J4[\"Safe by default\"]\n end\n\n style T4 fill:#ff8787,stroke:#000,color:#000\n style J4 fill:#69db7c,stroke:#000,color:#000\n style T1 fill:#00ceff,stroke:#000,color:#000\n style J1 fill:#00ceff,stroke:#000,color:#000\n```\n\n\n**Interview Insight:** When asked about RAII in multithreading, `std::jthread` is the perfect example. It applies the same resource management principles to threads that `std::unique_ptr` applies to memory.\n\n### Creating jthreads\n\nYou can create jthreads the same way as threads, plus with the automatic stop_token integration.\n\n\n```cpp\n// Without stop token (just like std::thread)\nstd::jthread t1([] {\n std::cout << \"Hello from jthread\\n\";\n});\n\n// With stop token (automatic first parameter)\nstd::jthread t2([](std::stop_token stoken) {\n while (!stoken.stop_requested()) {\n do_work();\n }\n});\n\n// With stop token and additional arguments\nstd::jthread t3([](std::stop_token stoken, int id) {\n while (!stoken.stop_requested()) {\n process(id);\n }\n}, 42);\n```\n\n\nThe magic happens when the callable's first parameter is a `std::stop_token`. The jthread detects this and automatically passes its internal token. If your callable doesn't take a stop_token, jthread works exactly like a regular thread, just with automatic joining.\n\n### Manual Stop Requests\n\nSometimes you need to stop a thread before it would naturally go out of scope. You can request a stop explicitly.\n\n\n```cpp\nstd::jthread t([](std::stop_token stoken) {\n while (!stoken.stop_requested()) {\n do_work();\n }\n});\n\n// Later...\nt.request_stop(); // Signal the thread to stop\n\n// Destructor will still join, waiting for thread to finish\n```\n\n\nThis is useful when you have multiple jthreads and need to coordinate their shutdown. Call `request_stop()` on each, then let their destructors handle the joining naturally.\n\nBut what if you need to share a cancellation signal across multiple threads? That brings us to the cooperative cancellation system.\n\n## Cooperative Cancellation: stop_token, stop_source, stop_callback\n\nThe stop token system provides a standardized way to request and observe cancellation. It's more than just a boolean flag. It's a complete cancellation protocol with three components.\n\n**std::stop_source**: The origin of stop requests. Only one source exists, but it can create many tokens.\n\n**std::stop_token**: A handle to observe stop requests. Cheap to copy and share. Multiple threads can hold tokens from the same source.\n\n**std::stop_callback**: Registers a callback to run when stop is requested. This is the key to cancelling blocking operations.\n\nThe following diagram shows the relationship between these components. One source creates multiple tokens, and callbacks can be attached to any token.\n\n\n```mermaid\nflowchart LR\n SOURCE[\"stop_source\"]\n TOKEN1[\"stop_token\"]\n TOKEN2[\"stop_token\"]\n TOKEN3[\"stop_token\"]\n CB1[\"stop_callback\"]\n CB2[\"stop_callback\"]\n\n SOURCE -->|\"get_token()\"| TOKEN1\n SOURCE -->|\"get_token()\"| TOKEN2\n SOURCE -->|\"get_token()\"| TOKEN3\n\n TOKEN1 --> CB1\n TOKEN2 --> CB2\n\n SOURCE -->|\"request_stop()\"| CB1\n SOURCE -->|\"request_stop()\"| CB2\n\n style SOURCE fill:#ff8787,stroke:#000,color:#000\n style TOKEN1 fill:#ffa94d,stroke:#000,color:#000\n style TOKEN2 fill:#ffa94d,stroke:#000,color:#000\n style TOKEN3 fill:#ffa94d,stroke:#000,color:#000\n style CB1 fill:#69db7c,stroke:#000,color:#000\n style CB2 fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Basic Usage\n\nThe simplest pattern is creating a stop_source and sharing its tokens with workers.\n\n\n```cpp\n#include \n#include \n#include \n\nvoid worker(std::stop_token stoken) {\n while (!stoken.stop_requested()) {\n do_work();\n }\n}\n\nint main() {\n std::stop_source source;\n\n std::thread t(worker, source.get_token());\n\n std::this_thread::sleep_for(std::chrono::seconds(1));\n\n source.request_stop(); // Signal all threads with tokens from this source\n\n t.join();\n}\n```\n\n\nAll threads holding tokens from the same source will see the stop request. This makes coordinated shutdown trivial.\n\n### stop_callback: Cancelling Blocking Operations\n\nHere's where the stop token system really shines. What if your thread is blocked on a system call when stop is requested? It can't check the token if it's not running. This is where `stop_callback` comes in.\n\n\n```cpp\nvoid worker(std::stop_token stoken) {\n // Register cleanup callback\n std::stop_callback callback(stoken, [] {\n std::cout << \"Stop requested! Cleaning up...\\n\";\n });\n\n while (!stoken.stop_requested()) {\n do_work();\n }\n}\n```\n\n\nThe callback executes:\n\n- On the thread that calls `request_stop()`, if stop is requested after callback registration\n- Immediately on the current thread, if stop was already requested before registration\n\nThis execution model is crucial for understanding how to use callbacks correctly. The following sequence diagram illustrates the flow.\n\n\n```mermaid\nsequenceDiagram\n participant Main as Main Thread\n participant Worker as Worker Thread\n participant CB as stop_callback\n\n Worker->>CB: Register callback\n Note over Worker: Continue working...\n\n Main->>Main: request_stop()\n Main->>CB: Execute callback\n Note over Main: Callback runs on
requesting thread\n\n Worker->>Worker: Check stop_requested()\n Worker->>Worker: Exit loop\n```\n\n\nNotice that the callback runs on the main thread (the one calling `request_stop()`), not the worker thread. This means you can use callbacks to unblock workers by, for example, closing a socket or signaling a condition variable.\n\n**Interview Insight:** A common interview question is how to cancel a thread blocked on I/O. The answer involves `stop_callback`: register a callback that closes the file descriptor or signals a condition variable, forcing the blocked operation to return with an error.\n\n### Stop Token with Condition Variables\n\nThe stop token integrates elegantly with condition variable waiting. This solves a long-standing problem: how do you wake a thread waiting on a condition variable when you want it to shut down?\n\n\n```cpp\n#include \n#include \n\nstd::mutex mtx;\nstd::condition_variable_any cv;\nstd::queue tasks;\n\nvoid worker(std::stop_token stoken) {\n while (true) {\n std::unique_lock lock(mtx);\n\n // Wait for task or stop, whichever comes first\n bool stopped = cv.wait(lock, stoken, [] {\n return !tasks.empty();\n });\n\n if (stopped || (stoken.stop_requested() && tasks.empty())) {\n return; // Shutting down\n }\n\n Task task = std::move(tasks.front());\n tasks.pop();\n lock.unlock();\n\n task.run();\n }\n}\n```\n\n\nNote the use of `std::condition_variable_any` instead of `std::condition_variable`. The former supports `stop_token` in its wait functions. The wait returns when either the predicate is satisfied OR stop is requested, with the return value indicating which occurred.\n\nThis brings us to the new synchronization primitives that complement jthread and stop_token.\n\n## std::latch: One-Time Barrier\n\nA `std::latch` is a single-use countdown synchronization primitive. You initialize it with a count, threads decrement it, and other threads wait for it to reach zero. Once zero, it stays zero forever.\n\nWhy do we need this when we have condition variables? Because latch eliminates the boilerplate. No mutex to manage, no predicate to write, no spurious wakeup handling. Just count down and wait.\n\n\n```cpp\n#include \n#include \n#include \n\nvoid parallel_initialization() {\n constexpr int num_workers = 4;\n std::latch done(num_workers);\n\n std::vector workers;\n for (int i = 0; i < num_workers; i++) {\n workers.emplace_back([&done, i] {\n initialize_component(i);\n done.count_down(); // Signal this worker is done\n });\n }\n\n done.wait(); // Block until all workers finish\n std::cout << \"All components initialized\\n\";\n}\n```\n\n\nThe latch starts at 4. Each worker decrements it after completing initialization. The main thread blocks at `wait()` until all four decrements happen. Clean, simple, no races.\n\n### Latch Operations\n\nThe latch API is minimal but complete.\n\n\n```cpp\nstd::latch l(5); // Initialize with count 5\n\nl.count_down(); // Decrement by 1\nl.count_down(3); // Decrement by 3\n\nl.wait(); // Block until count reaches 0\n\nl.try_wait(); // Non-blocking check (returns bool)\n\nl.arrive_and_wait(); // count_down() then wait()\n```\n\n\nThe `arrive_and_wait()` combination is particularly useful when a worker both contributes to the count and needs to wait for others.\n\nThe following state diagram shows the latch lifecycle. Once it reaches zero, there's no going back.\n\n\n```mermaid\nstateDiagram-v2\n [*] --> Active: latch(N)\n\n Active --> Active: count_down()\n Active --> Zero: count_down() when count becomes 0\n\n Zero --> [*]: All waiters released\n\n note right of Active: Threads wait here\n note right of Zero: Cannot be reused\n\n classDef active fill:#ffa94d,stroke:#000,color:#000\n classDef zero fill:#69db7c,stroke:#000,color:#000\n\n class Active active\n class Zero zero\n```\n\n\nBut what if you need to synchronize threads multiple times, not just once? That's where barriers come in.\n\n## std::barrier: Reusable Synchronization Point\n\nUnlike `latch`, `std::barrier` can be reused. Threads synchronize at the barrier, then continue together. This pattern repeats for multiple phases, making it perfect for iterative parallel algorithms.\n\n\n```cpp\n#include \n#include \n#include \n\nvoid iterative_algorithm() {\n constexpr int num_threads = 4;\n constexpr int num_iterations = 10;\n\n std::barrier sync_point(num_threads, [] {\n // Completion function: runs once per phase, by one thread\n std::cout << \"Phase complete\\n\";\n });\n\n std::vector workers;\n for (int i = 0; i < num_threads; i++) {\n workers.emplace_back([&sync_point, i] {\n for (int iter = 0; iter < num_iterations; iter++) {\n compute_partial_result(i, iter);\n sync_point.arrive_and_wait(); // Synchronize\n }\n });\n }\n}\n```\n\n\nThe completion function is optional but powerful. It runs exactly once per phase, on one of the arriving threads. Use it to aggregate results, reset state, or print progress. No external synchronization needed.\n\nThe following diagram shows how threads flow through barrier phases. All threads must arrive before any can proceed to the next phase.\n\n\n```mermaid\nflowchart LR\n subgraph Phase1[\"Phase 1\"]\n P1T1[\"Thread 1: work\"]\n P1T2[\"Thread 2: work\"]\n P1T3[\"Thread 3: work\"]\n end\n\n B1[\"Barrier
(all arrive)\"]\n\n subgraph Complete1[\"Completion\"]\n C1[\"Completion function
(one thread)\"]\n end\n\n subgraph Phase2[\"Phase 2\"]\n P2T1[\"Thread 1: work\"]\n P2T2[\"Thread 2: work\"]\n P2T3[\"Thread 3: work\"]\n end\n\n B2[\"Barrier
(all arrive)\"]\n\n Phase1 --> B1\n B1 --> Complete1\n Complete1 --> Phase2\n Phase2 --> B2\n\n style B1 fill:#ff8787,stroke:#000,color:#000\n style B2 fill:#ff8787,stroke:#000,color:#000\n style C1 fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Dynamic Participant Count\n\nWhat if a worker needs to exit early? The barrier supports this with `arrive_and_drop()`.\n\n\n```cpp\nstd::barrier sync(4);\n\nvoid worker(int id, bool should_leave_early) {\n for (int phase = 0; phase < 10; phase++) {\n do_work(id, phase);\n\n if (should_leave_early && phase == 5) {\n sync.arrive_and_drop(); // Leave barrier permanently\n return;\n }\n\n sync.arrive_and_wait();\n }\n}\n```\n\n\nAfter `arrive_and_drop()`, the barrier expects one fewer arrival in subsequent phases. This is useful for workers that complete their portion early or encounter errors.\n\n**Interview Insight:** When asked about parallel algorithms, mention barriers for iterative methods like Jacobi iteration, parallel sorting phases, or simulation steps. The key insight is that all threads must complete a phase before any can start the next.\n\nNow let's look at semaphores, which solve a different synchronization problem entirely.\n\n## std::counting_semaphore and std::binary_semaphore\n\nSemaphores control access to a resource with a counter. A thread can acquire (decrement) if the counter is positive, or wait if it's zero. Releasing increments the counter. Unlike mutexes, semaphores have no ownership, so any thread can release, not just the one that acquired.\n\nThe classic use case is resource pooling. Say you have 5 database connections and 20 threads that need them. A semaphore initialized to 5 ensures only 5 threads hold connections at once.\n\n\n```cpp\n#include \n#include \n#include \n\nconstexpr int max_connections = 5;\nstd::counting_semaphore connection_pool(max_connections);\n\nvoid client_request(int id) {\n connection_pool.acquire(); // Wait for available connection\n\n use_connection(id);\n\n connection_pool.release(); // Return connection to pool\n}\n\nint main() {\n std::vector clients;\n for (int i = 0; i < 20; i++) {\n clients.emplace_back(client_request, i);\n }\n}\n```\n\n\nTwenty threads contend for 5 slots. At most 5 run `use_connection()` concurrently. The rest wait at `acquire()` until a slot opens.\n\n### Semaphore Types\n\nC++20 provides two semaphore types.\n\n\n```cpp\n// Counting semaphore with max value\nstd::counting_semaphore<100> sem(10); // Max 100, initial 10\n\n// Binary semaphore (optimized for 0/1)\nstd::binary_semaphore sem(1); // Initial 1 (available)\n// Equivalent to: std::counting_semaphore<1> sem(1);\n```\n\n\nBinary semaphore is optimized for the common case of signaling between threads. It's not a mutex (no ownership), but it can implement mutex-like behavior when needed.\n\n### Use Case: Producer-Consumer with Bounded Buffer\n\nSemaphores shine in producer-consumer scenarios. Two semaphores track empty slots and full slots, naturally enforcing the buffer bounds.\n\n\n```cpp\ntemplate\nclass BoundedBuffer {\n std::array buffer_;\n size_t head_ = 0, tail_ = 0;\n std::mutex mtx_;\n std::counting_semaphore empty_{Size}; // Empty slots\n std::counting_semaphore full_{0}; // Full slots\n\npublic:\n void push(T item) {\n empty_.acquire(); // Wait for empty slot\n\n {\n std::lock_guard lock(mtx_);\n buffer_[tail_] = std::move(item);\n tail_ = (tail_ + 1) % Size;\n }\n\n full_.release(); // Signal item available\n }\n\n T pop() {\n full_.acquire(); // Wait for item\n\n T item;\n {\n std::lock_guard lock(mtx_);\n item = std::move(buffer_[head_]);\n head_ = (head_ + 1) % Size;\n }\n\n empty_.release(); // Signal slot available\n return item;\n }\n};\n```\n\n\nThe diagram below shows how the two semaphores coordinate producers and consumers. The producer decrements `empty` and increments `full`. The consumer does the opposite.\n\n\n```mermaid\nflowchart LR\n subgraph Producer\n P[\"push()\"]\n end\n\n subgraph Semaphores\n EMPTY[\"empty (slots)\"]\n FULL[\"full (items)\"]\n end\n\n subgraph Buffer\n B[\"Bounded Buffer\"]\n end\n\n subgraph Consumer\n C[\"pop()\"]\n end\n\n P -->|\"acquire\"| EMPTY\n P -->|\"write\"| B\n P -->|\"release\"| FULL\n\n C -->|\"acquire\"| FULL\n C -->|\"read\"| B\n C -->|\"release\"| EMPTY\n\n style EMPTY fill:#69db7c,stroke:#000,color:#000\n style FULL fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThis pattern eliminates busy-waiting and guarantees the buffer never overflows or underflows. The semaphores do all the heavy lifting.\n\nWith the new synchronization primitives covered, let's look at how C++20 improved atomics.\n\n## Atomic Improvements in C++20\n\nC++20 brings several atomic improvements that eliminate common workarounds. Each addresses a real pain point from earlier C++ versions.\n\n### atomic wait and notify\n\nBefore C++20, waiting for an atomic value to change meant spinning.\n\n\n```cpp\n// Old way: wasteful spinning\nwhile (flag.load() == false) {\n std::this_thread::yield();\n}\n```\n\n\nEven with `yield()`, this burns CPU cycles. The thread keeps waking up just to check a value and go back to sleep.\n\nC++20 atomics support wait/notify operations, similar to condition variables but without a mutex.\n\n\n```cpp\n#include \n#include \n\nstd::atomic data{0};\n\nvoid consumer() {\n data.wait(0); // Block until data != 0\n int value = data.load();\n process(value);\n}\n\nvoid producer() {\n prepare_data();\n data.store(42);\n data.notify_one(); // Wake one waiter\n // or: data.notify_all(); // Wake all waiters\n}\n```\n\n\nWhy does this matter? Performance. Under the hood, `wait()` uses OS primitives like futex (Linux), WaitOnAddress (Windows), or ulock_wait (macOS). The thread actually sleeps instead of spinning, consuming no CPU while waiting.\n\n**Interview Insight:** When asked about spin-lock vs blocking, `atomic::wait()` provides a middle ground. It's simpler than condition variables (no mutex) but efficient like them (OS-level blocking).\n\n### std::atomic_ref\n\nSometimes you need atomic operations on non-atomic variables. Perhaps you're interfacing with C code, working with memory-mapped hardware, or have a struct where only some accesses need to be atomic.\n\n\n```cpp\nstruct SharedData {\n int counter; // Non-atomic (for C interop, etc.)\n // ... other fields\n};\n\nvoid atomic_update(SharedData& data) {\n std::atomic_ref ref(data.counter);\n ref.fetch_add(1, std::memory_order_relaxed);\n}\n```\n\n\nImportant constraint: while any `atomic_ref` to an object exists, ALL accesses must go through `atomic_ref`. Mixing atomic and non-atomic access is undefined behavior.\n\n### Floating-Point Atomics\n\nC++20 adds atomic operations for floating-point types.\n\n\n```cpp\nstd::atomic sum{0.0};\n\nvoid accumulate(double value) {\n sum.fetch_add(value, std::memory_order_relaxed);\n}\n```\n\n\nBefore C++20, this required awkward compare-exchange loops.\n\n\n```cpp\n// Pre-C++20 workaround for atomic floating-point add\nvoid old_accumulate(std::atomic& sum, double value) {\n double expected = sum.load();\n while (!sum.compare_exchange_weak(expected, expected + value)) {\n // Retry on failure\n }\n}\n```\n\n\nThe new `fetch_add` for floats is both cleaner and potentially more efficient.\n\n### std::atomic_flag Improvements\n\n`std::atomic_flag` gained `test()` and wait/notify operations.\n\n\n```cpp\nstd::atomic_flag flag = ATOMIC_FLAG_INIT;\n\n// New in C++20:\nbool value = flag.test(); // Read without modifying\n\nflag.wait(false); // Block until flag is true\nflag.notify_one(); // Wake one waiter\n```\n\n\nPreviously, the only way to read an `atomic_flag` was `test_and_set()`, which always set it. Now you can observe without modifying.\n\nThese atomic improvements complement the synchronization primitives nicely. But there's one more feature that deserves attention: thread-safe output.\n\n## std::osyncstream: Thread-Safe Output\n\nOutput stream operations aren't atomic. Without synchronization, concurrent writes interleave unpredictably.\n\n\n```cpp\n// Without osyncstream: output can mix\nstd::thread t1([] { std::cout << \"Hello from thread 1\\n\"; });\nstd::thread t2([] { std::cout << \"Hello from thread 2\\n\"; });\n// Might output: \"HelHello lo from thread 2from thread 1\\n\\n\"\n```\n\n\nThis happens because each `<<` operation is separate. Thread 1 might output \"Hel\", then thread 2 outputs \"Hello from thread 2\\n\", then thread 1 continues with \"lo from thread 1\\n\".\n\n`std::osyncstream` ensures each output sequence is atomic.\n\n\n```cpp\n#include \n#include \n\nvoid safe_output() {\n std::jthread t1([] {\n std::osyncstream(std::cout) << \"Hello from thread 1\\n\";\n });\n\n std::jthread t2([] {\n std::osyncstream(std::cout) << \"Hello from thread 2\\n\";\n });\n}\n// Output is never interleaved\n```\n\n\nThe output is buffered internally and written atomically when the `osyncstream` is destroyed.\n\n\n```cpp\n{\n std::osyncstream out(std::cout);\n out << \"Part 1 \";\n out << \"Part 2 \";\n out << \"Part 3\\n\";\n} // All three parts written atomically here\n```\n\n\nThis is particularly useful for logging in multithreaded applications. Each log message appears intact, even under heavy concurrency.\n\n## Integrating C++20 Primitives\n\nThe real power of C++20 concurrency features comes from combining them. Let's see how stop_token works with barrier for graceful parallel algorithm shutdown.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nvoid parallel_computation(std::stop_token stoken) {\n constexpr int num_threads = 4;\n\n // Barrier with completion function that checks for stop\n std::atomic should_stop{false};\n std::barrier sync(num_threads, [&] {\n // Check stop condition between phases\n if (stoken.stop_requested()) {\n should_stop.store(true);\n }\n std::osyncstream(std::cout) << \"Phase complete\\n\";\n });\n\n std::vector workers;\n for (int i = 0; i < num_threads; i++) {\n workers.emplace_back([&sync, &should_stop, i](std::stop_token) {\n while (!should_stop.load()) {\n compute_partial(i);\n sync.arrive_and_wait();\n }\n });\n }\n\n // Workers will stop at next barrier phase\n}\n\nint main() {\n std::jthread computation(parallel_computation);\n\n std::this_thread::sleep_for(std::chrono::seconds(5));\n // computation goes out of scope, triggering stop\n}\n```\n\n\nThe barrier's completion function checks the stop token between phases. All workers finish their current phase, then exit together. Clean coordinated shutdown without races.\n\n## Migrating a Thread Pool to jthread\n\nLet's see a concrete migration example. Here's a simple thread pool using `std::thread`.\n\n\n```cpp\n// Pre-C++20 thread pool\nclass OldThreadPool {\n std::vector workers;\n std::queue> tasks;\n std::mutex mtx;\n std::condition_variable cv;\n std::atomic stop{false};\n\npublic:\n OldThreadPool(size_t n) {\n for (size_t i = 0; i < n; i++) {\n workers.emplace_back([this] {\n while (true) {\n std::function task;\n {\n std::unique_lock lock(mtx);\n cv.wait(lock, [this] {\n return stop || !tasks.empty();\n });\n if (stop && tasks.empty()) return;\n task = std::move(tasks.front());\n tasks.pop();\n }\n task();\n }\n });\n }\n }\n\n ~OldThreadPool() {\n stop = true;\n cv.notify_all();\n for (auto& t : workers) t.join(); // Must not forget!\n }\n\n void submit(std::function task) {\n {\n std::lock_guard lock(mtx);\n tasks.push(std::move(task));\n }\n cv.notify_one();\n }\n};\n```\n\n\nAnd here's the C++20 version using jthread and condition_variable_any.\n\n\n```cpp\n// C++20 thread pool\nclass ModernThreadPool {\n std::vector workers;\n std::queue> tasks;\n std::mutex mtx;\n std::condition_variable_any cv;\n\npublic:\n ModernThreadPool(size_t n) {\n for (size_t i = 0; i < n; i++) {\n workers.emplace_back([this](std::stop_token stoken) {\n while (true) {\n std::function task;\n {\n std::unique_lock lock(mtx);\n // wait() returns true if stop was requested\n if (cv.wait(lock, stoken, [this] {\n return !tasks.empty();\n })) {\n if (tasks.empty()) return; // Stop requested, no tasks\n }\n task = std::move(tasks.front());\n tasks.pop();\n }\n task();\n }\n });\n }\n }\n\n // Destructor automatically requests stop and joins!\n // ~ModernThreadPool() = default;\n\n void submit(std::function task) {\n {\n std::lock_guard lock(mtx);\n tasks.push(std::move(task));\n }\n cv.notify_one();\n }\n};\n```\n\n\nKey differences:\n\n- No manual `stop` flag, jthread handles it\n- No manual `join()` in destructor\n- `condition_variable_any` integrates with stop_token\n- Workers exit cleanly when stop is requested\n\n## Comparison of C++20 Primitives\n\n\n| Primitive | Use Case | Reusable? | Wait Support |\n|-----------|----------|-----------|--------------|\n| `std::latch` | One-time multi-thread sync | No | Yes |\n| `std::barrier` | Repeated multi-thread sync | Yes | Yes |\n| `counting_semaphore` | Resource pool limiting | Yes | Yes (timed) |\n| `binary_semaphore` | Mutex-like signaling | Yes | Yes (timed) |\n| `stop_token` | Cooperative cancellation | N/A | Via callbacks |\n| `atomic::wait` | Efficient value monitoring | N/A | Yes |\n\n\n## Common Mistakes\n\n### Mistake 1: Forgetting jthread Has Different Destruction Semantics\n\nWith `std::jthread`, destruction requests stop AND joins. This is usually what you want, but it can surprise you if you expect the thread to continue running.\n\n\n```cpp\nvoid surprising() {\n std::jthread t([](std::stop_token st) {\n while (!st.stop_requested()) {\n do_work(); // This might get interrupted!\n }\n });\n\n // Unexpected early return\n if (error) return; // jthread destructor requests stop!\n}\n```\n\n\nIf you need the thread to outlive a scope, move it to a longer-lived container.\n\n### Mistake 2: Using condition_variable with stop_token\n\n\n```cpp\n// WRONG: condition_variable doesn't support stop_token\nstd::condition_variable cv; // Use condition_variable_any instead!\ncv.wait(lock, stoken, predicate); // Won't compile!\n\n// CORRECT\nstd::condition_variable_any cv;\ncv.wait(lock, stoken, predicate); // OK\n```\n\n\nOnly `condition_variable_any` has the overload that accepts a stop_token.\n\n### Mistake 3: Latch Underflow\n\n\n```cpp\nstd::latch l(3);\nl.count_down();\nl.count_down();\nl.count_down();\nl.count_down(); // UNDEFINED BEHAVIOR: count goes negative\n```\n\n\nCalling `count_down()` more times than the initial count is undefined behavior. Track your counts carefully.\n\n### Mistake 4: Barrier with Wrong Participant Count\n\n\n```cpp\nstd::barrier b(4); // Expects 4 threads\n\n// Only 3 threads call arrive_and_wait:\n// DEADLOCK! Barrier waits forever for 4th arrival\n```\n\n\nThe barrier count must match the actual number of threads that will participate. Use `arrive_and_drop()` if a thread needs to exit early.\n\n### Mistake 5: Semaphore Release Without Acquire\n\n\n```cpp\nstd::counting_semaphore<10> sem(5);\n\nsem.release(); // Now count is 6\nsem.release(); // Now count is 7\n// ... keep releasing without acquiring\nsem.release(); // Eventually exceeds max: UNDEFINED BEHAVIOR\n```\n\n\nUnlike mutexes, semaphores don't track ownership. Releasing without prior acquire is valid up to the maximum, but exceeding it is undefined behavior.\n\n## Interview Questions\n\n### Q1: What problem does std::jthread solve compared to std::thread?\n\n**Answer:** `std::jthread` solves two problems:\n\n1. **Automatic joining**: `std::thread`'s destructor calls `std::terminate()` if the thread is joinable (not joined or detached). This is a common source of bugs. `std::jthread`'s destructor automatically requests stop and joins the thread.\n\n1. **Cooperative cancellation**: `std::jthread` integrates with `std::stop_token`, providing a standardized way to request thread termination. With `std::thread`, you need to roll your own flag mechanism.\n\n\n```cpp\n// std::thread: must manually manage\nstd::atomic stop{false};\nstd::thread t([&] { while (!stop) work(); });\nstop = true;\nt.join(); // Must not forget!\n\n// std::jthread: automatic\nstd::jthread t([](std::stop_token st) { while (!st.stop_requested()) work(); });\n// Destructor handles everything\n```\n\n\n### Q2: When would you use std::latch vs std::barrier?\n\n**Answer:**\n\nUse **std::latch** for one-time synchronization:\n\n- Waiting for all workers to complete initialization\n- Signaling that multiple async operations have finished\n- Cannot be reused after count reaches zero\n\nUse **std::barrier** for repeated synchronization:\n\n- Iterative algorithms where threads must sync after each iteration\n- Pipeline stages where all threads must complete before moving to next stage\n- Supports a completion function that runs between phases\n\n\n```cpp\n// Latch: one-time wait for N things\nstd::latch ready(N);\nfor (worker : workers) ready.count_down();\nready.wait(); // All workers initialized\n\n// Barrier: repeated sync points\nstd::barrier sync(N);\nfor (int iter = 0; iter < 100; iter++) {\n compute();\n sync.arrive_and_wait(); // Sync after each iteration\n}\n```\n\n\n### Q3: How does std::stop_callback help with resource cleanup?\n\n**Answer:** `std::stop_callback` registers code to run when stop is requested. This is useful for:\n\n1. **Cancelling blocking operations**: If a thread is blocked on I/O, the callback can close the file descriptor to unblock it.\n\n1. **Cleaning up resources**: Release locks, close connections, free memory.\n\n1. **Cascading cancellation**: Propagate stop request to child operations.\n\n\n```cpp\nvoid worker(std::stop_token stoken) {\n Socket socket = connect_to_server();\n\n // If stop is requested, close socket to unblock recv()\n std::stop_callback cleanup(stoken, [&socket] {\n socket.close();\n });\n\n while (!stoken.stop_requested()) {\n auto data = socket.recv(); // Blocking, but will fail if socket closed\n if (data) process(*data);\n }\n}\n```\n\n\nThe callback is called on the thread that calls `request_stop()`, not the waiting thread. This allows immediate action even if the target thread is blocked.\n\n### Q4: What's the advantage of atomic wait/notify over spin-waiting?\n\n**Answer:** Spin-waiting wastes CPU cycles:\n\n\n```cpp\n// Spin-wait: burns CPU\nwhile (flag.load() == false) {\n std::this_thread::yield();\n}\n```\n\n\n`atomic::wait()` uses the operating system's wait mechanism:\n\n\n```cpp\n// Efficient wait: thread sleeps\nflag.wait(false);\n```\n\n\nUnder the hood, `wait()` typically uses:\n\n- **Linux**: futex (fast userspace mutex)\n- **Windows**: WaitOnAddress\n- **macOS**: ulock_wait\n\nThese put the thread to sleep until notified, consuming no CPU. When `notify_one()` or `notify_all()` is called, the OS wakes the appropriate threads.\n\nThe difference is significant under contention: spin-waiting can saturate CPU cores, while wait/notify lets them do useful work or save power.\n\n### Q5: Explain the difference between counting_semaphore and mutex.\n\n**Answer:**\n\nA **mutex** provides mutual exclusion: exactly one thread can hold it at a time. It has ownership, the thread that locks must unlock.\n\nA **counting_semaphore** is a counter: any thread can acquire (decrement) or release (increment), regardless of who did previous operations. It allows N concurrent accesses.\n\n\n| Feature | std::mutex | std::counting_semaphore |\n|---------|-----------|------------------------|\n| Max concurrent holders | 1 | N (configurable) |\n| Ownership | Yes (same thread locks/unlocks) | No (any thread can release) |\n| Use case | Mutual exclusion | Resource pooling, rate limiting |\n| RAII support | lock_guard, unique_lock | Manual acquire/release |\n\n\n\n```cpp\n// Mutex: one at a time\nstd::mutex m;\n{ std::lock_guard lock(m); /* exclusive access */ }\n\n// Semaphore: up to 5 at a time\nstd::counting_semaphore<5> sem(5);\nsem.acquire(); // Can have 5 concurrent acquires\n/* use resource */\nsem.release(); // Don't need to be same thread\n```\n\n\n## Summary\n\nC++20 significantly improves concurrency support with primitives that make common patterns safer and more expressive.\n\n**Key Additions:**\n\n\n| Feature | Purpose |\n|---------|---------|\n| `std::jthread` | Auto-joining thread with stop token |\n| `std::stop_token` | Cooperative cancellation |\n| `std::latch` | One-time countdown barrier |\n| `std::barrier` | Reusable phase synchronization |\n| `std::counting_semaphore` | N-way resource limiting |\n| `std::atomic::wait/notify` | Efficient atomic waiting |\n| `std::osyncstream` | Thread-safe stream output |\n\n\n**Migration Guide:**\n\n\n| Old Pattern | C++20 Replacement |\n|-------------|-------------------|\n| `std::thread` + manual join | `std::jthread` |\n| `std::atomic` stop flag | `std::stop_token` |\n| Spin-waiting on atomic | `atomic::wait()/notify()` |\n| `std::condition_variable` for counting | `std::latch` or `std::barrier` |\n| Manual semaphore with mutex + cv | `std::counting_semaphore` |\n| Mutex around std::cout | `std::osyncstream` |\n\n\n**Best Practices:**\n\n1. Prefer `std::jthread` over `std::thread` for automatic cleanup\n2. Use `std::stop_token` for graceful shutdown\n3. Use `std::latch` for one-time initialization barriers\n4. Use `std::barrier` for iterative algorithms with sync points\n5. Use `std::counting_semaphore` for resource pools and rate limiting\n6. Use `atomic::wait()` instead of spin-waiting\n\nThe primitives work even better together. Use jthread with barrier for parallel algorithms that need graceful shutdown. Use stop_callback with condition_variable_any for interruptible waits. Use osyncstream for readable concurrent logging.\n\nC++20's concurrency primitives make common patterns safer and more expressive. They reduce boilerplate, eliminate common bugs, and improve performance by using OS-level waiting instead of spinning.\n\n## References\n\n- [C++ Reference: std::jthread](undefined)\n- [C++ Reference: std::stop_token](undefined)\n- [C++ Reference: std::latch](undefined)\n- [C++ Reference: std::barrier](undefined)\n- [C++ Reference: std::counting_semaphore](undefined)\n- [Anthony Williams: C++ Concurrency in Action, 2nd Edition](undefined)\n- [Nicolai Josuttis: C++20 - The Complete Guide](undefined)","pageType":"concurrency-interview"}

C++20 Concurrency Features

Ashish Pratap Singh

Get Premium