Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6317534
Votes 1
Synopsis CyclicBarrier should have a cancel() method
Category java:classes_util_concurrent
Reported Against
Release Fixed
State 5-Cause Known, request for enhancement
Priority: 3-Medium
Related Bugs
Submit Date 30-AUG-2005
Description
A DESCRIPTION OF THE REQUEST :
A break() method would break the barrier, so all current and future waiters will get a BrokenBarrierException.

JUSTIFICATION :
In the code I'm working on, there is a situation where a barrier has been created, and code in other threads has been set in motion to cross a CyclicBarrer.  The time comes when it's too late for them to be allowed to go ahead and use the barrier, so the code in the main thread wants to put the barrier into a broken state to prevent them from successfully crossing the barrier.  There is currently no way to do that.


CUSTOMER SUBMITTED WORKAROUND :
I marked "Difficult to make even minimal  customer " in the absence of a choice like "It is impossible for me to make my code completely robust with out this fix".
Posted Date : 2005-08-30 12:37:18.0

The submitter adds:

"The method name can't be break(), of course (D'Oh!). I probably should have said cancel(). 

And this proposed method should return the number of exceptions thrown or a Collection of the affected threads, so you can tell if you caused any BrokenBarrierExceptions to be thrown."
Posted Date : 2005-09-07 02:01:46.0

An anonymous SDN commenter adds:

"In a similar vein, i'm working with a CyclicBarrier where some of the participating threads may encounter an exception.  when that happens, i'd like all the threads to bailout.  however, there's no way for the failed thread to signal that status reliably.  i would like a method like this that could be put in a finally block at the end of the thread code so that the other threads do not hang waiting for the failed thread.""
Posted Date : 2006-05-19 20:33:11.0
Work Around
The thread that wants to "cancel" the barrier can simply enter it with its own interrupt status set:

  Thread current = Thread.currentThread();
  boolean wasInterrupted = current.isInterrupted();
  if (!wasInterrupted)
    current.interrupt();
  try {
      barrier.await();
      assert false;
  }
  catch (InterruptedException ex) { /* expected */ }
  catch (BrokenBarrierException ex) { /* possible: someone did our job for us */ }
  if (wasInterrupted)
    current.interrupt();
Evaluation
A difficult design problem.

A failing thread could:
- set a shared volatile isBroken flag in its "finally" block, 
  which could be examined by the barrier action
- call reset()
- call await with a timeout of zero
- could interrupt waiting threads somehow (but that would require
  additional coordination)
Posted Date : 2006-05-19 20:33:11.0
Comments
  
  Include a link with my name & email   

Submitted On 02-SEP-2005
daveyost
The method name can't be break(), of course (D'Oh!). I probably should have said cancel(). 

And this proposed method should return the number of exceptions thrown or a Collection of the affected threads, so you can tell if you caused any BrokenBarrierExceptions to be thrown.


Submitted On 18-MAY-2006
In a similar vein, i'm working with a CyclicBarrier where some of the participating threads may encounter an exception.  when that happens, i'd like all the threads to bailout.  however, there's no way for the failed thread to signal that status reliably.  i would like a method like this that could be put in a finally block at the end of the thread code so that the other threads do not hang waiting for the failed thread.



PLEASE NOTE: JDK6 is formerly known as Project Mustang