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.

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;
}

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.

Latches and barriers

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

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; });

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.