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: 6358852
Votes 1
Synopsis Add methods on concurrent data structures that interrupt blocked threads
Category java:classes_util_concurrent
Reported Against
Release Fixed
State 3-Accepted, request for enhancement
Priority: 4-Low
Related Bugs
Submit Date 05-DEC-2005
Description
A DESCRIPTION OF THE REQUEST :
Add functionality to the concurrent data structures in java.util.concurrent that cause all threads that are currently blocked on calls to that data structure to be interrupted.

For instance, the method interruptWaitingThreads could be added to BlockingQueue that interrupts all threads that are blocked on a call to poll() (or, since poll() is defined in Queue and is not allowed to throw an InterruptedException, calls to a new pollInterruptably() method).


JUSTIFICATION :
Many blocking operations, for instance Semaphore.acquire, can throw InterruptedExceptions, and it is natural to use this to implement 'stop' operations on threads: the caller sets a flag and interrupts the thread, the thread wakes up, notices the flag, and returns.  This technique is also suggested in the API as a replacement for Thread.stop.

The API for BlockingQueue says that "A BlockingQueue does _not_ intrinsically support any kind of 'close' or 'shutdown' operation to indicate that no more items will be added" but suggests that end-of-stream objects could be used.  This RFE suggests extending the API to allow the same technique as Thread.stop to be used when closing data structures.  For instance, a worklist implemented using a LinkedBlockingQueue can implement a 'close' operation by setting an internal flag and then interrupting all waiting threads.  They then wake up, check that flag and return.  Implementing this using end-of-stream objects is undesirable both because it introduces a different way of working with blocking calls and because it is, to me, not as clean a solution.  Also, it is not immediately obvious (at least to me) how you would even implement closing a worklist when N threads block on a call to LinkedBlockingQueue.take() other than writing N end-of-stream objects.
Posted Date : 2005-12-05 07:10:45.0
Work Around
N/A
Evaluation
N/A
Comments
  
  Include a link with my name & email   

Submitted On 06-DEC-2005
cplesner
Correction: The method BlockingQueue.poll() mentioned in the description cannot actually block the caller; replace with take() and takeInterruptably().



PLEASE NOTE: JDK6 is formerly known as Project Mustang