Comments on: Thread coordination with CountDownLatch and CyclicBarrier

By: Confluence: Fritt om fag

Confluence: Fritt om fag — Thu, 29 Apr 2010 06:11:42 +0000

Java-tips…

Tips om Java Fundamentale teknikker Identitetskrise om identitet i Javaobjekter, inkludert {{equals/hashCode/Comparable}} Eksepsjonell kode om exceptions Om serialisering…

By: Ashley Williams

Ashley Williams — Wed, 22 Jul 2009 08:26:36 +0000

Let me qualify that a little: in a real world project the thread allocation policy and the task logic might not nicely be co-located in the same file. Then a developer might come along and swap the fixed thread executor to one with fewer threads as we are encouraged to do with the executor framework, without realizing the impact until the application freezes.

I take your point that with discipline this wouldn’t happen, just checking my understanding of cyclic barriers really.

Great concurrency refcard b.t.w.

By: Alex

Alex — Tue, 21 Jul 2009 16:38:29 +0000

I don’t know if I’d say it was dangerous. You’re correct that the thread count and barrier participants must be linked but as long as that invariant is maintained I think it’s fine.

This is kind of a common problem with barriers in that the participant count must be a) known in advance and b) fixed. The new Phaser class being added in JDK 7 is more flexible in this regard as the participant count can change during the life of the phaser.

By: Ashley Williams

Ashley Williams — Tue, 21 Jul 2009 16:20:46 +0000

Isn’t it a little dangerous to mix the barrier with the executor in this way? If you were to change the execution policy so that for example fewer threads were used then the threads won’t get released.

So it looks like the tasks and the execution policy are coupled tightly to the thread count.

By: Rishabh

Rishabh — Mon, 23 Mar 2009 03:54:45 +0000

nice article.
However i’d like to point out that the best use of cyclicbarrier is when a few threads want to wait for each other to reach a certain point. Bear in mind that the parent thread does not stop for the child threads unless u barrier.await(); on threads+1.

If u want that the parent thread should wait for the children then countdownlatch is the way to go. You can create a latch with the number_of_threads and then each thread can just countDown(); and the parent can await() on the same latch.