[concurrency-interest] Disposing a BlockingQueue with capacity?

Peter Veentjer alarmnummer at gmail.com
Sun Mar 4 12:37:56 EST 2007


> your solution isn'It 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.
It depends on the environment it is being used in.

> 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).

You could create a blockingqueue decorator that can be 'shutdown' (by
interrupting pending puts)

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