[concurrency-interest] ThreadPoolExecutor

David Holmes dholmes at dltech.com.au
Thu Oct 6 18:57:00 EDT 2005


> Just a little surprising is all, though I'm not sure how the
> ThreadPoolExecutor could know that a queue is non-synchronous?

A check of BlockingQueue.remainingCapacity would tell whether the queue was
bounded or not - but it would be subjective as to how big a value
"unbounded" really is.

> Actually isn't corePoolSize==0 an invalid usage pattern if the queue has
> *any* capacity at all?

With an infinite queue, or a queue you don't expect to fill then it is a
problem. However, you could use a zero core size and a small queue to
effectively "batch" tasks.

ThreadPoolExecutor is quite flexible but a side effect of that is that some
combinations of options make little or no sense.

> What we have is lots of threads active at a time doing things like
> waiting for a database or network response so our pools need to be
> pretty big to accommodate all these IO blocking calls.  I'd love to move
> to an event driven non-blocking IO model but unfortunately key
> technologies such as JDBC don't provide any such options.

I see. At this stage "fixing" the pool is probably a better option than
redesigning the core application architecture.

> I'll just maintain a modified version for myself (and anyone else if
> interested, just let me know).

I'm intrigued enough to try and implement that dual queue set up. :)

Cheers,
David Holmes



More information about the Concurrency-interest mailing list