Synchronization Primitives

Start with the invariant

Before choosing a primitive, decide what you are protecting:

• one shared object
• a reader/writer data structure
• a limited pool of resources
• a multi-step parallel phase

The primitive should match the coordination problem.

If the rule is unclear, the primitive choice will be unclear too. Start by writing one sentence such as "only one thread may mutate the cache at a time" or "at most eight workers may use the pool concurrently."

std::shared_mutex

Use this when reads are frequent and writes are rare.

std::shared_mutex cache_mutex;
std::unordered_map<std::string, int> cache;

int lookup(std::string_view key) {
    std::shared_lock lock(cache_mutex);
    return cache.at(std::string{key});
}

void update(std::string key, int value) {
    std::unique_lock lock(cache_mutex);
    cache[std::move(key)] = value;
}

This is useful for read-mostly structures, but it is not automatically faster than std::mutex. Measure contention before paying the extra complexity cost.

Semaphores

Use a semaphore when several tasks may proceed concurrently, but only up to a fixed limit.

std::counting_semaphore<8> db_slots(8);

This is often a better fit than a mutex when you are modeling capacity instead of exclusive ownership.

void use_slot() {
    db_slots.acquire();
    do_query();
    db_slots.release();
}

Latches and barriers

• std::latch: one-time coordination, such as "all workers are initialized".
• std::barrier: repeated step-by-step synchronization across iterations.

std::latch ready(3);

void worker() {
    prepare();
    ready.count_down();
    ready.wait();
    run();
}

Use std::barrier instead when the threads must meet again after each phase, not just once at startup.

Condition variables still matter

Condition variables remain the right tool when threads must sleep until a state predicate becomes true.

cv.wait(lock, [] { return ready; });

Condition variables remain the standard tool for "sleep until this state becomes true". Always make the state explicit and keep the wait predicate next to it.

Comparison guide

• mutex: exclusive access to a shared invariant.
• shared_mutex: mostly reads, rare writes, measured contention.
• condition_variable: sleep until a predicate becomes true.
• counting_semaphore: cap concurrent access to a resource pool.
• latch: one-time rendezvous.
• barrier: reusable phased rendezvous.

Worked coordination example

std::mutex queue_mutex;
std::condition_variable queue_cv;
std::queue<int> jobs;
std::counting_semaphore<2> worker_slots(2);
std::barrier phase_done(3);
bool done = false;

void worker() {
    while (true) {
        worker_slots.acquire();

        std::unique_lock lock(queue_mutex);
        queue_cv.wait(lock, [&] { return done || !jobs.empty(); });

        if (done && jobs.empty()) {
            worker_slots.release();
            break;
        }

        int job = jobs.front();
        jobs.pop();
        lock.unlock();

        process(job);
        worker_slots.release();
        phase_done.arrive_and_wait();
    }
}

This example is intentionally small, but it shows how the primitives differ:

• condition_variable waits for work to appear
• counting_semaphore caps concurrent active workers
• barrier marks the end of a processing phase

Most real systems do not need all three at once. The point is to match each primitive to one rule instead of trying to force one primitive to model everything.

Common mistakes

• protecting different parts of one invariant with different locks
• waiting without a predicate
• holding a lock during slow I/O or long computation
• choosing atomics for a problem that is really about a larger shared data structure

Practical choice rule

• if the question is "who owns access right now?" start with a mutex
• if the question is "when should sleeping threads wake up?" use a condition variable
• if the question is "how many workers may proceed at once?" use a semaphore
• if the question is "when does the whole group move to the next phase?" use a latch or barrier

Exercises

• Identify one mutex-protected design that really models a resource pool and sketch a semaphore version.
• Describe a staged parallel algorithm that would fit a barrier.
• Review one shared-data function and write down the invariant the lock is protecting.