Java Doc for CyclicBarrier.java in  » Ajax » Laszlo-4.0.10 » EDU » oswego » cs » dl » util » concurrent » Java Source Code / Java DocumentationJava Source Code and Java Documentation

CyclicBarriers use an all-or-none breakage model for failed synchronization attempts: If threads leave a barrier point prematurely because of timeout or interruption, others will also leave abnormally (via BrokenBarrierException), until the barrier is restarted. This is usually the simplest and best strategy for sharing knowledge about failures among cooperating threads in the most common usages contexts of Barriers. This implementation has the property that interruptions among newly arriving threads can cause as-yet-unresumed threads from a previous barrier cycle to return out as broken. This transmits breakage as early as possible, but with the possible byproduct that only some threads returning out of a barrier will realize that it is newly broken. (Others will not realize this until a future cycle.) (The Rendezvous class has a more uniform, but sometimes less desirable policy.)

Barriers support an optional Runnable command that is run once per barrier point.

Sample usage Here is a code sketch of a barrier in a parallel decomposition design.

 class Solver {
 final int N;
 final float[][] data;
 final CyclicBarrier barrier;
 class Worker implements Runnable {
 int myRow;
 Worker(int row) { myRow = row; }
 public void run() {
 while (!done()) {
 processRow(myRow);
 try {
 barrier.barrier(); 
 }
 catch (InterruptedException ex) { return; }
 catch (BrokenBarrierException ex) { return; }
 }
 }
 }
 public Solver(float[][] matrix) {
 data = matrix;
 N = matrix.length;
 barrier = new CyclicBarrier(N);
 barrier.setBarrierCommand(new Runnable() {
 public void run() { mergeRows(...); }
 });
 for (int i = 0; i < N; ++i) {
 new Thread(new Worker(i)).start();
 waitUntilDone();
 }
 }
 

[ Introduction to this package. ]