Synchronization Primitives

Core building blocks

• std::mutex: exclusive lock.
• std::shared_mutex: many readers or one writer.
• std::condition_variable: wait for state changes.
• std::counting_semaphore: limit concurrent access to a pool.
• std::latch: one-shot rendezvous.
• std::barrier: repeated phase synchronization.

Choose the primitive by the rule you need

• Use std::mutex when one thread at a time may touch shared mutable state.
• Use std::shared_mutex when reads dominate and writes are relatively rare.
• Use std::condition_variable when threads should sleep until a state change happens.
• Use std::counting_semaphore when a fixed number of workers may enter a region concurrently.
• Use std::latch when multiple threads must finish setup before anyone continues.
• Use std::barrier when threads advance through multiple synchronized phases.

Reader-writer locking

std::shared_mutex mutex;

void read_value() {
    std::shared_lock lock(mutex);
}

void write_value() {
    std::unique_lock lock(mutex);
}

Use this only when you have measured read-heavy contention. A plain mutex is often simpler and fast enough.

Semaphores

std::counting_semaphore<4> slots(4);

Use semaphores when access should be capped instead of fully serialized.

slots.acquire();
use_connection();
slots.release();

This pattern fits connection pools, worker slots, or rate-limited resources.

Coordination tools

• latch: workers finish setup before the next step begins.
• barrier: multiple threads repeat phased work together.

Condition variable pattern

std::mutex guard;
std::condition_variable cv;
std::queue<int> work;
bool done = false;

void consumer() {
    std::unique_lock lock(guard);
    cv.wait(lock, [&] { return done || !work.empty(); });
}

Always wait with a predicate. That protects you from spurious wakeups and documents the actual condition being awaited.

Latch vs barrier

• latch is single-use: all participants arrive once, then continue.
• barrier is reusable: participants meet, continue to the next phase, and can meet again.

std::latch ready(3);
ready.count_down();
ready.wait();

Practical guidance

• Prefer simple mutex-based designs before lock-free ideas.
• Protect invariants, not just individual variables.
• Keep waits predicate-based and cancellation-aware when possible.

Common failure modes

• Locking the wrong mutex for a shared invariant.
• Waiting without a predicate and assuming one notify means one wakeup.
• Holding a lock longer than necessary while doing slow work.
• Mixing atomics and locks without documenting which invariant each mechanism protects.

Relationship to atomics

Atomics coordinate individual memory operations. Synchronization primitives coordinate larger invariants and ownership of critical sections. If your rule is about a whole data structure, a mutex is usually the right starting point.