Multithreading

An atomic operation completes without visible intermediate state — other threads see it as fully done or not done. std::atomic<T> makes load, store, fetch_add, and compare_exchange indivisible.

Use RAII wrappers — never lock()/unlock() manually: lock_guard is simplest, unique_lock is movable and needed by condition_variable, scoped_lock (C++17) locks multiple mutexes atomically.

A data race is concurrent access to the same memory with at least one write and no sync — UB. A race condition is the broader logical bug where correctness depends on timing. A critical section must execute atomically.

Mutex with lock_guard/unique_lock to protect shared data; condition_variable for producer-consumer; std::atomic for single-variable updates; std::promise/future for one-shot transfer.

If a std::thread object is still joinable when its destructor runs, the program calls std::terminate() immediately. You must explicitly join or detach it before destruction.

C++ guarantees concurrent reads of the same object, concurrent calls on different objects of the same type, std::atomic ops, and thread-safe init of function-local static (C++11). Concurrent read+write on a non-atomic object is a data race — UB.

Lock a unique_lock, then call cv.wait(lock, predicate) — it atomically releases the lock and blocks. On notify the thread re-acquires the lock and re-checks the predicate. A spurious wakeup is when wait returns without a notify.

Deadlock is when threads wait on each other forever — usually from locking mutexes in different orders. Prevent it with a global lock order, short scopes, and std::scoped_lock for multiple mutexes.

Mutexes, locks (lock_guard/unique_lock/scoped_lock), condition_variable, atomics, and C++20 latch/barrier/semaphore. lock_guard is the simplest RAII wrapper: locks on construction, unlocks on destruction.

Concurrency structures a program so multiple tasks make progress over overlapping time. Parallelism is executing tasks literally simultaneously on different cores. A concurrent program may run in parallel — but doesn't have to.

A mutex has ownership — only the locker can unlock it. A semaphore is a signalling primitive with a counter; any thread can signal it. C++20 adds std::counting_semaphore/binary_semaphore.

launch::async runs the task on a new thread immediately; launch::deferred runs it lazily in the caller on get(). The default may silently defer, and the future destructor blocks under async.

Multithreading runs OS threads truly parallel on cores. Asynchrony starts a task and gets its result later, possibly on the same thread via an event loop. Threads give physical parallelism.

Concurrent reads are safe; any concurrent write is a data race. front() + pop_front() is a TOCTOU race: thread A holds the reference while B calls pop_front() and destroys the element.

A std::counting_semaphore (C++20) holds a counter, so it admits up to N concurrent holders, not one. It has no ownership — any thread may release() a permit another thread acquire()d, which fits cross-thread signalling and bounded resource pools.

C++11 added std::thread, mutexes, condition_variable, atomics, future/async. C++17 added shared_mutex and parallel STL. C++20 added jthread, latch, barrier, semaphore, coroutines.

Data race: ++counter is an unsynchronized read-modify-write across threads, which is undefined behavior, so the final value is unpredictable. Fix with std::atomic<int> counter{0} (then ++counter is atomic) or guard the increment with a std::mutex + lock_guard.

std::jthread joins automatically in its destructor (no terminate() if you forget) and integrates with std::stop_token for cooperative cancellation via request_stop() and stop_requested().

Both (C++20) make threads wait until a counter hits zero. A std::latch is single-use: count it down once and it is spent. A std::barrier is reusable: each arrive_and_wait resets it for the next phase and can run a completion function between phases.

Deadlock from lock-ordering inversion: t1 locks m1 then m2; t2 locks m2 then m1. If each takes its first lock at once, neither can take the second. Fix: lock in one consistent global order, or use std::scoped_lock lk(m1, m2) (C++17), which locks both atomically.

Defines when stores in one thread become visible to another via std::atomic with memory orderings (seq_cst, acq_rel, relaxed) and the happens-before relation. Before C++11 there was no portable threading model.

Use a mutex to protect invariants spanning multiple operations or variables. Use atomics for simple independent state like counters or flags. Atomics do not automatically make compound logic safe.

std::recursive_mutex lets the same thread acquire the lock multiple times without deadlocking. lock() increments an internal counter and unlock() decrements it; release happens at zero.

std::shared_mutex (C++17) has shared (read) mode for many threads and exclusive (write) mode for one. Use std::shared_lock for reads and std::unique_lock for writes.

For several mutexes, std::scoped_lock (C++17) calls std::lock, a deadlock-avoidance algorithm: it tries, backs off and retries on conflict, so no fixed acquisition order is needed. It then holds them RAII-style and unlocks all in the destructor.

A spinlock busy-waits in a loop instead of yielding the CPU, avoiding the syscall overhead of mutex sleep/wake. It is faster only when the critical section is very short; longer holds waste CPU.

An exception escaping a std::thread function calls std::terminate. To propagate across threads use std::future/std::async (rethrown on get()) or std::exception_ptr to capture and transport manually.

Pre-spawn N workers waiting on a shared task queue protected by a mutex and condition variable. submit() enqueues a std::function<void()> and notifies one worker; the destructor sets a stop flag and joins.

A bounded queue under a mutex with two condition variables: not_full (producer waits if full) and not_empty (consumer waits if empty). Graceful shutdown uses a done_ flag — consumers drain on done_ && queue_.empty().

thread_local gives each thread its own independent copy of a variable, initialized on first access and destroyed when the thread exits.

std::atomic<T> makes read-modify-write operations indivisible. Orderings: relaxed, acquire/release, acq_rel, and seq_cst (total global order, default).

A minimal Atomic<T> wraps a value and mutex with load/store/compare_exchange_strong. A real std::atomic<T> for trivially-copyable types uses lock-free CPU instructions via intrinsics — no mutex needed.

No. A flock() lock belongs to the open file description, not to a thread. All threads of one process share that fd, so they all see the same lock and flock() never blocks one against another. It is advisory locking between processes; use a std::mutex for threads.

Deadlock: threads stuck waiting on each other with no progress. Livelock: threads run and change state in response to each other but no useful work happens — usually from naive retry logic without jitter.

CPU-bound tasks: one thread per logical core (hardware_concurrency()); I/O-bound tasks: more threads than cores since they mostly wait; Amdahl's Law caps the speedup by the sequential fraction.

ABA: a compare_exchange reads A, another thread changes it to B and back to A, so the CAS succeeds though the structure changed underneath. Mitigate it with a tagged pointer (a version counter bumped per update) or hazard pointers.

Double-checked locking reads a lazy pointer without lock, then locks and re-checks. Pre-C++11 it was UB because a thread could see a non-null pointer but uninitialised fields.

False sharing is when two threads write distinct variables that share one cache line — each write invalidates the other core's copy, causing line ping-pong. Fix it by aligning hot data to std::hardware_destructive_interference_size.

atomic_thread_fence(order) is a standalone barrier that orders prior and subsequent operations in the current thread without performing any atomic load or store. Putting release/acquire on the atomic op is usually simpler.

Lock-free: at least one thread always makes progress (no deadlock, but individuals can starve). Wait-free: every thread finishes in a bounded number of steps — the strongest guarantee.

A memory barrier prevents reordering of memory ops across it. Acquire (load): later ops stay after; release (store): earlier ops stay before. A release/acquire pair makes the writer's prior writes visible to the reader.

A high-priority thread waits on a lock held by a low-priority one while medium-priority threads preempt the holder. Mitigated by priority inheritance, priority ceiling, or short critical sections.

Minimize shared mutable state, document thread-safety guarantees explicitly, encapsulate RAII locks at class boundaries, never hold locks across user callbacks, and expose atomic compound operations instead of separate check/act methods.