[concurrency-interest] A thread pool for servers?

David M. Lloyd david.lloyd at redhat.com
Mon Sep 14 08:17:33 EDT 2015

Where would you pull from, if not a queue?

On 09/12/2015 09:06 AM, Viktor Klang wrote:
> Doug,
> yes, pre prospect of making thread pools *pull* in work rather than get
> *pushed* work would make for a very interesting side-effect in terms of
> flow control / back pressure without having to block any threads in the
> process.
> On Sat, Sep 12, 2015 at 2:18 PM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
>     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
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> --
> Cheers,
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


More information about the Concurrency-interest mailing list