CyclicBarrier In Java With Examples

Thread synchronization can significantly impact your application’s performance and reliability.
As you probe Java’s concurrency utilities, you’ll discover CyclicBarrier as a powerful tool for coordinating multiple threads.
This comprehensive guide will walk you through everything you need to know about implementing CyclicBarrier in your applications, from basic concepts to advanced implementation patterns.
Whether you’re building a distributed computing system or managing complex parallel processes, you’ll learn how to leverage CyclicBarrier effectively in your concurrent programming tasks.

Understanding CyclicBarrier

A CyclicBarrier is a synchronization aid in Java’s concurrency framework that allows a set number of threads to wait for each other to reach a common barrier point before any of them proceed.
Like a checkpoint in a race, it allows multiple threads to pause until all participants arrive.
When you create a CyclicBarrier, you specify the number of threads that must call await() before the barrier is tripped and threads can proceed.
This is particularly useful in scenarios where multiple threads need to collaborate on a task, ensuring that all threads have completed a certain phase of execution before moving on to the next phase.
When the specified number of threads reach the barrier, they are all released to continue processing.

This mechanism can be utilized in various scenarios such as parallel processing, simulations, and iterative computations where tasks can be divided into phases.

The CyclicBarrier can be reset for reuse after the barrier has been tripped, making it cyclical.
Developers can even provide a barrier action, which is a piece of code that runs once when the barrier is tripped, facilitating additional operations or computations at that synchronization point.
Thus, the CyclicBarrier enhances the coordination of multi-threaded tasks, making them more efficient and easier to manage.

CyclicBarrier Components

A CyclicBarrier consists of two main components:

• a count of waiting threads
• an optional barrier action

When you initialize a CyclicBarrier, you set the party count, which determines how many threads must arrive before the barrier opens.

Threads call await() to signal they’ve reached the barrier point, and the barrier tracks the count of arrived threads.
Once all expected threads arrive, the barrier executes any defined barrier action and releases all waiting threads.
This barrier action is supplied as a runnable object in CyclicBarrier constructor.

You can reuse the barrier for multiple synchronization cycles, making it particularly useful for iterative algorithms.

Initializing CyclicBarrier

You can create a CyclicBarrier instance by passing the number of threads that should wait at the barrier in its constructor.
These threads are called parties. Here’s a basic example:

int partyCount = 3; 
CyclicBarrier barrier = new CyclicBarrier(partyCount); 

// With barrier action 
CyclicBarrier barrierWithAction = new CyclicBarrier(partyCount, 
                                        () -> System.out.println("Barrier point 
                                   reached!"));

CyclicBarrier Real Life Example

Imagine some hikers plan a trek.
All the hikers will reach a common point and wait for each other.
They won’t proceed until all hikers have arrived.

This is exactly how CyclicBarrier works in Java!
Threads call await() and then wait at a barrier until all have arrived, and then they continue execution simultaneously..

Here’s an example of how to use CyclicBarrier in your code:

import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierExample {
  public static void main(String[] args) {
    int numberOfHikers = 5;
    // Creating a CyclicBarrier for 5 threads (hikers)
    CyclicBarrier barrier = new CyclicBarrier(numberOfHikers, () -> 
         System.out.println("All hikers reached the checkpoint!"+
                            "Moving ahead together"));

    for (int i = 1; i <= numberOfHikers; i++) {
      new Thread(new Hiker(barrier, "Hiker " + i)).start();
    }
  }
}

class Hiker implements Runnable {
  private CyclicBarrier barrier;
  private String name;

  public Hiker(CyclicBarrier barrier, String name) {
    this.barrier = barrier;
    this.name = name;
  }

  @Override
  public void run() {
    try {
      System.out.println(name + " is trekking...");
      // Simulating different trekking times
      Thread.sleep((long) (Math.random() * 3000)); 
      System.out.println(name + " reached the checkpoint!");
      // Wait at the barrier
      barrier.await();
      System.out.println(name + " is continuing the journey!");
    } catch (InterruptedException | BrokenBarrierException e) {
      e.printStackTrace();
    }
  }
}

Each thread calls await() when it reaches the barrier.
Execution will pause at this point until all 5 threads have called await().
Once all threads arrive, they proceed together.

Before all threads reach await() → Execution is paused.
After all threads call await() → Execution resumes.

This ensures proper synchronization without unnecessary delays! 

Barrier Actions and Callbacks

Mechanism of barrier actions provides you with the ability to execute specific code when all threads reach the barrier point.
This callback is executed by the last thread that arrives at the barrier, before any threads are released.

This feature enables you to implement complex synchronization patterns.
Here’s an example demonstrating barrier action usage:

CyclicBarrier barrier = new CyclicBarrier(3, () -> { System.out.println("All threads arrived!"); 

When To Use CyclicBarrier ?

CyclicBarrier is useful in scenarios where multiple threads must wait for each other before proceeding. Some practical use cases include:

Parallel Data Processing – Splitting a large dataset into chunks for multi-threaded processing, then merging the results.
Game Development – Synchronizing multiple players before starting a new game round.
Scientific Simulations – Running multiple calculations in parallel and combining the results.

CyclicBarrier vs CountDownLatch

CyclicBarrier and CountDownLatch are both synchronization aids provided by the Java Concurrency framework, each serving distinct purposes in multi-threaded programming.
A CountDownLatch is utilized when one or more threads need to wait until a set of operations performed by other threads is completed.
Once the countdown reaches zero, all waiting threads are released. It is a one-time use object, meaning that once the count has reached zero, it cannot be reset.

On the other hand, a CyclicBarrier allows a set of threads to all wait for each other to reach a common barrier point before proceeding.
Unlike CountDownLatch, which is a one-time use, CyclicBarrier can be reused for multiple operations, making it suitable for iterative problems where threads need to synchronize multiple times.
This feature of CyclicBarrier allows for greater flexibility in complex applications that require synchronized phases of execution.

CyclicBarrier vs Semaphore

CyclicBarrier and Semaphore are both synchronization constructs that help manage access to shared resources and coordinate activities among multiple threads in concurrent programming.
A CyclicBarrier allows a set of threads to wait for each other at a common barrier point until all have reached it.
This mechanism is useful when a task is divided into subtasks that can be executed in parallel, and a collective result is needed before proceeding.
Once all threads reach the barrier, they can continue their execution together.

On the other hand, a Semaphore controls access to resources by maintaining a count that represents the number of available permits.
Threads can acquire permits to access limited resources and must release them when done.
This is particularly useful for managing thread pools or limiting access to a finite number of connections in applications.
While Semaphores can manage a variable number of threads, CyclicBarriers are specific to scenarios where synchronization after a task completion is essential.

Integration with ExecutorService

You can combine CyclicBarrier with ExecutorService to create powerful concurrent processing solutions:

ExecutorService executor = Executors.newFixedThreadPool(3); 
CyclicBarrier barrier = new CyclicBarrier(3, () -> { 
                              System.out.println("All tasks completed"); 
                        }); 
for (int i = 0; i < 3; i++) { 
  executor.submit(() -> { 
     try { 
        barrier.await(); 
     } catch (Exception e) { 
       // Handle exceptions 
     } 
  }); 
}

Summing up

CyclicBarrier is a synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point before continuing their execution.
It is particularly useful in scenarios where multiple threads need to execute phases of computation that are interdependent.
By using a CyclicBarrier, developers ensure that all threads have finished their current tasks before any of them proceed to the next phase, thus enabling coordinated execution and improving overall application performance.