A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
Barriers coordinate multiple threads or processes by requiring all participants to reach a synchronization point before proceeding. They are essential in parallel applications where iterations or phases must complete synchronously. A simple barrier implementation uses mutexes and condition variables to count arrivals and signal when all participants have arrived.
You already understand the synchronization problem: multiple threads sharing resources need coordination to avoid races and ensure correct behavior. Semaphores and mutexes solve the problem of protecting shared data from concurrent access. Barriers solve a different coordination problem — ensuring that all threads reach the same point in execution before any of them move forward. Think of it like a group of hikers agreeing to regroup at each trail marker before continuing: nobody proceeds until everyone has arrived.
The canonical use case is iterative parallel computation. Imagine a physics simulation where the world is divided into spatial regions, each handled by a separate thread. In each time step, every thread computes new values based on the current state of its region and its neighbors' regions. But no thread can start step N+1 until every thread has finished step N — otherwise a thread might read a neighbor's half-updated state. A barrier at the end of each iteration guarantees this: every thread computes, hits the barrier, waits, and only proceeds to the next iteration once all threads have arrived.
A simple barrier implementation works as follows. A shared counter starts at zero, protected by a mutex. When a thread reaches the barrier, it acquires the mutex, increments the counter, and checks whether the counter equals the total number of participating threads. If not, the thread releases the mutex and blocks on a condition variable, waiting to be woken up. When the last thread increments the counter to the total, it resets the counter to zero and broadcasts on the condition variable, waking all waiting threads. This is called a centralized barrier — all threads converge on a single counter.
Centralized barriers are simple but can become bottlenecks when the thread count is large, because every thread must acquire the same mutex sequentially. For high-performance parallel programs, tree barriers and butterfly barriers reduce contention by organizing threads into pairs or groups that synchronize locally before propagating the "all arrived" signal up a tree structure. The POSIX `pthread_barrier_t` provides a standard centralized barrier interface, but understanding the underlying mutex-and-condition-variable mechanism helps you reason about performance tradeoffs and build custom synchronization patterns when the standard barrier does not fit your problem's structure.