CountDownLatch Vs CyclicBarrier in Java

Both CountDownLatch and CyclicBarrier are synchronization aids in Java concurrency that facilitate communication among threads. Both of these synchronization aids create a latch or a barrier to make threads wait until a condition is satisfied and then only the threads can make further progress. In this post we’ll see the difference between CountDownLatch and CyclicBarrier in Java.

CountDownLatch and CyclicBarrier

CyclicBarrier- A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point.
CountDownLatch- A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.

CountDownLatch Vs CyclicBarrier in Java

1- Initialization:

A CountDownLatch is initialized with a given count where count denotes the number of times countDown() must be invoked before threads can pass through await().

A CyclicBarrier is initialized with a given number of parties, where parties denotes the number of threads and the CyclicBarrier trips when the given number of parties (threads) are waiting upon it.

This initialization makes CountDownLatch more versatile synchronization tool-

A CountDownLatch initialized with a count of one serves as a simple on/off latch, or gate: all threads invoking await wait at the gate until it is opened by a thread invoking countDown().
A CountDownLatch initialized to N can be used to make one thread wait until N threads have completed some action, or some action has been completed N times.

With CyclicBarrier you specify the number of threads that are waiting upon it which means if you have a CyclicBarrier initialized to 3 then 3 threads should invoke await() on this barrier to trip the barrier. That makes CyclicBarrier more useful for scenario involving a fixed sized party of threads that must occasionally wait for each other.

2- Reusability:

One of the main difference between CountDownLatch and CyclicBarrier is that CountDownLatch can’t be reused. Once the count has reached zero for the CountDownLatch instance the count cannot be reset.

CyclicBarrier can be re-used after the waiting threads are released.

3- Optional Runnable:

CyclicBarrier class has a constructor where a Runnable barrierAction can be provided.

public CyclicBarrier(int parties, Runnable barrierAction)

The given barrier action is executed when the barrier is tripped, performed by the last thread entering the barrier.

So there is an option to execute a separate Runnable action with CyclicBarrier.

CountDownLatch class in Java doesn't have any such constructor to specify a runnable action.

4- Exception:

The CyclicBarrier uses an all-or-none breakage model for failed synchronization attempts: If a thread leaves a barrier point prematurely because of interruption, failure, or timeout, all other threads waiting at that barrier point will also leave abnormally via BrokenBarrierException (or InterruptedException if they too were interrupted at about the same time).

If any thread is interrupted while waiting, then all other waiting threads will throw BrokenBarrierException and the barrier is placed in the broken state.
If the barrier is reset() while any thread is waiting, or if the barrier is broken when await is invoked, or while any thread is waiting, then BrokenBarrierException is thrown.

With CountDownLatch if a current thread is interrupted while waiting then InterruptedException is thrown.

That's all for the topic CountDownLatch Vs CyclicBarrier in Java. If something is missing or you have something to share about the topic please write a comment.

You may also like

KnpCode

March 6, 2024