|
Quick Lists
|
|
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
|
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
|
|
|
 |