[concurrency-interest] A thread pool for servers?

Doug Lea dl at cs.oswego.edu
Sat Sep 12 08:18:55 EDT 2015


On 09/11/2015 05:51 PM, Martin Buchholz wrote:
>
> Colleague Douglas Dickinson at Google pointed out that none of the convenience
> executors in Executors is truly resource bounded.

It's great that people are advocating use of the resource-control
features of TPE. Back in pre-j.u.c days when TPE was introduced,
nearly everyone complained about how many arguments were needed in
the constructor, which led to us introducing Executors convenience
methods. But in these cases "convenience" means "we are letting you
get away with default choices that you should probably someday revisit",
and the TPE javadoc includes discussion about how to make better choices.
The need to contemplate bounding, rejection, and flow control
has been increasing as containerized, resource-managed runtime
environments become more common.

But, like David, I'm not sure that we can add more Executors methods
that don't amount to just replicating the TPE constructors.
Maybe a builder, but that seems like overkill given the j.u.c audience.

Some of these issues also affect ForkJoinPool, which we addressed by
adding a configurable spare-thread limit and tolerance for bounded
thread factories. It would also be possible to add a per-thread local
queue-size limit, although the cases where it might come into play
are uncommon and preventable using FJ status methods.

People facing these issues might also consider using the new
SubmissionPublisher class, that pushes resource and flow control
up one level: Producers need to pick buffer sizes, consumers
explicitly perform requests, and you must choose per-item
whether to use block vs drop vs timeout vs handler modes
(methods submit, offer, and timed-offer, with optional drop
handlers). These can be made to work well no matter what kind
Executor you use, because the SubmissionPublisher deals with
most of them instead of the Executor.

> (and of course, we can try to write an actual better bounded thread pool not
> based on ThreadPoolExecutor, but that's actually hard)

The main use case that j.u.c. lacks explicit coverage for
is when there is known to be a single task submitter thread.
FJP's multi-laned queues add some unnecessary data structure overhead
and TPE's insistence on a queue implementation meeting the full
BlockingQueue API adds some unnecessary sync overhead.
In most usages, either choice is fine, but we might consider
addressing this.

-Doug





More information about the Concurrency-interest mailing list