Why does Java have both CountDownLatch and CyclicBarrier?

Question

I am reading multi threading and came across these to multithreading concepts, I read the difference and when we should be using these, but I am not able to understand why Java has two classes which do same work?

CyclicBarrier can do everything that CountDownLatch does, then why isCountDownLatch in the Java standard library?

Answer 1

A short, not overly detailed answer... And first a link to their respective javadocs:

• CountDownLatch;
• CyclicBarrier.

tl;dr: the main difference is that unlike a CyclicBarrier, once a CountDownLatch is done and over with, it cannot be reused. The javadoc mentions it explicitly:

This is a one-shot phenomenon -- the count cannot be reset. If you need a version that resets the count, consider using a CyclicBarrier.

And indeed, we find that a CyclicBarrier has a method called .reset(), which does what it means. Not only that, but there is a version of the constructor of a CyclicBarrier which associated a Runnable to be run each time the barrier is "tripped" (that is what the javadoc says; don't ask me).

So, those are indeed different, for the simple fact that one is reusable (CyclicBarrier) while the other is not (CountDownLatch).

Answer 2

CyclicBarrier can do everything that CountDownLatch does, then why isCountDownLatch in the Java standard library?

Not really.

The biggest difference between the two is not that one is reusable and the other is not. The difference is when state is changed. For latch - when someone (that's the key!) calls countDown() method, while for Barrier - when a thread (that's the key) reaches await() method.

So basically, we have different units of measurement here - one operates in terms of number of calls to countDown() while the other with number of waiting threads

Consider 2 examples:

// thread 1
for (int i = 0; i < 10; i++) {
  latch.countDown() //perfectly fine
}

//thread 2
for (int i = 0; i < 10; i++) {
  barrier.await() //oops 
}

Considering that effectively both are counters for different things their features somehow intersect.

Answer 3

You are talking about a common question. Sometimes indeed some classes provided by JDK are functionally overlapping.

Another example is CountDownLatch and Semaphore. Basically you can replace one with another without much difference in functionality. This post: CountDownLatch vs. Semaphore may help in your confusion.

I think you can choose one which can make your code easier to understand. In your case, if you use a CyclicBarrier it will never reset itself, so you would better use CountDownLatch which makes the code easier to understand.

Take the constructor of Semaphore for example: JDK provides two constructors

1     public Semaphore(int permits) {
2         sync = new NonfairSync(permits);
3     }

and

1     public Semaphore(int permits, boolean fair) {
2         sync = fair ? new FairSync(permits) : new NonfairSync(permits);
3     }

we can use Semaphore(3,false) to replace Semaphore(3) without any difference, both of them are constructing a Non-fair version semaphore. But why does JDK still provide two versions of constructors? Because choosing the right one from them can make the code easier to read and understand.

Answer 4

Here's my 2 cents:

The CountDownLatch allows thread A to wait for thread B, but not requiring thread B to wait for thread A. This can be used on scenario when one thread is required to work uninterruptedly, while the other must synchronize on some points on that thread.

On the other hand CyclicBarrier requires the 2 threads to synchronize on each other, which is the core different between the two.

Answer 5

Apart from the standard differences, the reason for having both is that they offer different functionalities and not really completely overlap. For example-

1. CyclicBarrier allows you to supply a Runnable that is executed everytime the barrier point is met, this can be used to update some common state, this can't be done by CountDownLatch.
2. In CyclicBarrier, if one thread encounters exception, all threads exit with an exception, this can't be done in CountDownLatch.

So, it really depends on your usecase which one to use.