Barrier
A barrier is a synchronization mechanism at which participating executions wait until the required participants or conditions are met before proceeding.
C++ Concurrency in Action, Second Edition
A synchronization primitive that makes participating threads wait until all have reached a synchronization point.
- How it is used
- Coordinates repeated steps among threads, preventing parallel partial-sum updates from getting ahead of one another.
- How deep it goes
- Works through atomic arrival counts, generation changes, yielding waits, and a changing participant count in C++ barrier implementations.
- Examples
- Uses a full roller coaster, a simple atomic barrier class, and a pairwise-update partial-sum implementation.
- What you can do after
- Build it from scratch in C++11 to synchronize repeated parallel steps, including cycles with a changing participant count.
Read how C++ Concurrency in Action, Second Edition explains barrier →
Learn Concurrent Programming with Go
A barrier is a synchronization mechanism that suspends participating executions until all of them reach the same execution point, after which they resume and may participate again.
- How it is used
- Synchronizes goroutines at common execution points between phases of concurrent work.
- How deep it goes
- Builds a reusable Go barrier with a condition variable, mutex, counter, and broadcast-based Wait() operation.
- Examples
- Demonstrates fast and slow goroutines rendezvousing and row goroutines performing repeated matrix multiplication phases.
- What you can do after
- Build it from scratch as a reusable Go barrier and apply it to coordinate repeated worker phases.
Read how Learn Concurrent Programming with Go explains barrier →
Kafka Streams in Action, Second Edition
A synchronization barrier is a coordination point at which consumers wait for assignment synchronization before processing can resume.
- How it is used
- Coordinates consumer-group reassignments so topic partitions never have multiple consumer owners.
- How deep it goes
- Traces JoinGroup and SyncGroup behavior, coordinator roles, ownership guarantees, and eager-versus-cooperative downtime.
- Examples
- Uses assignment diagrams and contrasting eager and cooperative rebalance figures to show when partition processing stops.
- What you can do after
- Evaluate rebalancing downtime and explain why processing waits for synchronized partition assignments.
Read how Kafka Streams in Action, Second Edition explains barrier →
Related concepts
- incremental pairwise algorithmuses · A parallel prefix-sum technique that repeatedly combines values with partial sums from increasingly larger distances.
- atomic operationcontrasts with · An atomic operation accesses or updates shared state as an indivisible action with respect to concurrent operations.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.