[concurrency-interest] Disposing a BlockingQueue with capacity?

David Holmes dcholmes at optusnet.com.au
Sun Mar 4 17:10:19 EST 2007


Oliver,

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

A "queue" is not really a service, so it would be up to the service using
the queue to have the API and implementation to handle this. For example
ThreadPoolExecutor's shutdown protocol takes care of pool thread's taking
from the queue, and client threads submitting to the queue.

It would have been possible to define BlockingQueue to have a close() method
that asynchronously shuts down the queue and releases all waiters - and of
course your own implementation of BlockingQueue could add this. The decision
not to have a close() method was a deliberate one, as per the docs:

"A BlockingQueue does not intrinsically support any kind of "close" or
"shutdown" operation to indicate that no more items will be added. The needs
and usage of such features tend to be implementation-dependent. For example,
a common tactic is for producers to insert special end-of-stream or poison
objects, that are interpreted accordingly when taken by consumers. "

Cheers,
David Holmes



More information about the Concurrency-interest mailing list