[concurrency-interest] A thread pool for servers?

Viktor Klang viktor.klang at gmail.com
Mon Sep 14 10:10:12 EDT 2015


A Publisher of Runnable?

On Mon, Sep 14, 2015 at 2:17 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> 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
>>
>>
> --
> - DML
>
> _______________________________________________
> 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/20150914/f5de23fb/attachment.html>


More information about the Concurrency-interest mailing list