One example is given by one of our trainers when he was explaining difference between CountDownLatch and CyclicBarrier.
CountDownLatch: Suppose a stone can be lifted by
Use case 1 Suppose you have split a large job into 10 small task, each one a thread. You have to wait for the 10 tasks' end from that threads before considering the job done.
So the main job initiator thread initializes a CountDownLatch to the number of threads used, it distributes tasks to threads and waits for the latch raises zero with await
method. Each executor thread will invoke countDown
at the end of its task. Finally the main thread will be waken when all threads have finished so it considers the all job is done. This scenario uses the doneSignal
latch describes in the CountDownLatch javadoc.
Use case 2 Suppose you have split a large job into a n * m tasks, distributed over n threads. m corresponds to a matrix row and you have a total to compute for each row. In that case, threads must be synchronized after each task ending so that the total for the row is compute. In that case, a CyclicBarrier
initialized with the number of threads n is used to wait for the end of each row computation (m times in fact).
To compare both, the CountDownLatch
is supposed to be used only 1 time and a CyclicBarrier
can be used as many times as the algorithm requires a synchronization point for a set of threads.
The key difference is that CountDownLatch
separates threads into waiters and arrivers while all threads using a CyclicBarrier
perform both roles.
Your latch example implies that all ten people must wait to lift the stone together. This is not the case. A better real world example would be an exam prompter who waits patiently for each student to hand in their test. Students don't wait once they complete their exams and are free to leave. Once the last student hands in the exam (or the time limit expires), the prompter stops waiting and leaves with the tests.
Theoretical Difference:
In CountDownLatch, main threads waits for other threads to complete their execution. In CyclicBarrier, worker threads wait for each other to complete their execution.
You can not reuse same CountDownLatch instance once count reaches to zero and latch is open, on the other hand CyclicBarrier can be reused by resetting Barrier, Once barrier is broken.
Real life example:--
CountDownLatch: Consider a IT world scenario where manager divided modules between development teams (A and B) and he wants to assign it to QA team for testing only when both the teams completes their task.
Here manager thread works as main thread and development team works as worker thread. Manager thread waits for development teams thread to complete their task.
CyclicBarrier: Consider the same IT world scenario where manager divided modules between development teams (A and B). He goes on leave and asked both team to wait for each other to complete their respective task once both are done assign it to QA team for testing.
Here manager thread works as main thread and development team works as worker thread. Development team threads wait for other development team threads after completing their task.
A cyclic barrier as the name suggests can be used in cycles. For ex: I am a company hr looking for N number of resumes from various job portal feeds. I have a skillset array containing skills sorted in order of priority. For ex java,c#,python. I want to find N resumes matching java skillset, but if I dont find the required no. of resumes, I search again on the next skillset and so on.
I create a worker each of which scans through the resumes, in the assigned job feeds. Both workers will start with the primary skillset search in their job feeds.
After performing the search worker will check if the N resumes were found. If found, the worker will reset the barrier and return. Else it will wait for the other worker to complete. If still N resumes were not found, the search would be resumed again, on the next skill in the skillset array. So, search can be called recursively/cyclicly without needing to create a new cyclic barrier.
CountDownLatch: If we want all of our threads to do
something + countdown
so that other waiting (for count to reach zero) threads can proceed, we can use countdown latch. All prior threads who actually did the countdown can go on in this situation but there is no guarantee that line processed after latch.countdown() will be after waiting for other threads to reach at latch.countdown() but it has a guarantee that other waiting threads will only start further after latch.await() has reached zero.
CyclicBarrier: If we want all our thread to
do something + await at common point + do something
(each await call will decrease wait time for threads to carry on further)
CyclicBarrier functionality can be achieved by CountDownLatch only once by calling latch.countdown() followed by latch.await() by all the threads.
but again you cant reset/reuse the countdownlatch.
Best example where I used CyclicBarrier is to initialize multiple caches (warmed by multiple threads) and then starting further processing, and I wanted to reinitialize other caches again in Sync.