[concurrency-interest] A thread pool for servers?

Viktor Klang viktor.klang at gmail.com
Sat Sep 12 10:06:27 EDT 2015


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> 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150912/71359986/attachment-0001.html>


More information about the Concurrency-interest mailing list