[concurrency-interest] Disposing a BlockingQueue with capacity?

Oliver Pfeiffer pfeiffer at tzi.de
Sun Mar 4 12:14:46 EST 2007


Hi Peter,

your solution isn't safe, since there is no reliable timeout value. If some
parts of the heap were swapped as virtual memory and the garbage collection
performs an intermediate run on a very slow and busy system it may need
seconds until the waiting threads become active again. Certainly this would
never happen under normal conditions but however it isn't bullet proof.

Actually I put all submitting threads to a HashSet and decouple the queue
from the black-box during shutdown. Then I can safely interrupt all threads
that are still waiting on the queue after the black-box was shut down to
avoid a black hole for submitter threads. :)

But I really prefer a more obvious solution provided by the queue itself,
since this is a very common use-case that must be handled by all APIs using
producer/consumer services based on blocking queues in a multithreaded
environment (where no assurances are met about the number of submitting
threads).

-- 
Grüße - Regards
Oliver Pfeiffer
ICQ-ID 84320006 

> -----Original Message-----
> From: Peter Veentjer [mailto:alarmnummer at gmail.com] 
> Sent: Sunday, March 04, 2007 5:59 PM
> To: Oliver Pfeiffer
> Cc: concurrency-interest at cs.oswego.edu
> Subject: RE: [concurrency-interest] Disposing a BlockingQueue 
> with capacity?
> 
> Hi Oliver,
> 
> what you could do is the following;
> 
> add a check before an item is put on the queue. when the structure
> shuts down, the check doesn';t allow any items being put by throwing
> an illegalstateexception for example, or
> thisstructureisshutdownexception.
> 
> Now for the waiting threads. When the structure is shut down, just
> take all items that are going to be put.
> 
> object item;
> do{
>     item = queue.poll(1,TimeUnit.SECOND)
> while(item1=null)
> 
> This make sure that pending threads (for putting) are allowed to run.
> 
> queue's are great structures, but I don't expose them directly in a
> lot of situations because the contract they provide can be
> restrictive.
> 
> You also have to watch out for discarding items, in some situations
> you don't want this to happen.
> 
> Another solution would be to interrupt all pending threads. But you
> need to have access to the pending threads.
> 
> On 3/4/07, Oliver Pfeiffer <pfeiffer at tzi.de> wrote:
> > How should a BlockingQueue with a fixed capacity be 
> disposed to release all
> > waiting submitter threads?
> >
> > Assuming we have a black-box service sequentially 
> processing items. The
> > items can be submitted to the black-box by 1..n threads in 
> parallel. The box
> > uses a LinkedBlockingQueue with a fixed capacity of 10. 
> When the queue
> > becomes full there could be more than 10 (e.g. 1000) 
> blocked threads waiting
> > to submit further items.
> >
> > How can this black-box safely be terminated by releasing 
> all submitter
> > threads? Unfortunately the capacity can't be set to infinity after
> > construction and a BlockingQueue#clear() does only clear 
> the currently
> > queued items. Thus in the example above we will release 10 threads
> > (successful submit) but will still have 990 threads blocked.
> >
> > --
> > Grüße - Regards
> > Oliver Pfeiffer
> > ICQ-ID 84320006
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >




More information about the Concurrency-interest mailing list