[concurrency-interest] Sharing threads across executors

gustav trede gustav.trede at gmail.com
Sun Mar 14 06:17:04 EDT 2010


The cost of having idle threads is not as the killer it used to be.
It tends to be the cost of the pools logic that is the problem, tracking the
queue and thread limits enforces lock/synchronized design that in general
gives sup optimal scalability unless work stealing or other tricks are used.
If your throughput needs of a pool is high and theres a need of many threads
:
Using a fixedpool based on a LinkedTransferQueue (a recent version: jdk7 or
Doug lea cvs) without queue limit can give vastly better throughput (and
hence a higher cpu usage).
Such a pool can still be resizable using poisons, it just dont resizes
itself.
For some special cases with very few threads and high contention, a lock
based like LBQ can still win albeit with a small marginal, but it just does
not scale.
Its quite implementation dependent and as LTQ and other aspects evolve, its
imo of constant interest to compare different designs in order to know whats
optimal for different usage cases.


On 14 March 2010 06:25, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> The mechanism for sharing a single threadpool across multiple executors is
> delegation, as in your implemented solution.
>
> Since a ScheduledThreadPoolExecutor is a type of ThreadPoolExecutor, why
> not make the STPE the root of your executor tree?  In which case, tasks that
> need immediate execution would be submitted via execute(), and only the
> delayed tasks would be be submitted via one of the schedule() methods.
>
> If you want the idle STPE threads to die off, can you use setKeepAliveTime
> and allowCoreThreadTimeOut?  Even though a STPE is constructed with a fixed
> core size, I *think* these methods will still behave in their specified way.
>
> Joe
>
> On Sat, Mar 13, 2010 at 5:09 PM, Dibyendu Majumdar wrote:
>
> Hi,
>>
>> I am building a system where there are many modules that need to run
>> background tasks. The requirement is that the tasks execute without blocking
>> as otherwise performance will be impacted. On the other hand I want to avoid
>> having too many threads sitting idle.
>>
>> I may have misunderstood, but it seems to me that there is no mechanism
>> for sharing a single threadpool across multiple executors. Conceptually, I'd
>> like each executor to have its task queue, but share the thread pool with
>> other executors, so that the pool of threads is optimised.
>>
>> I also need the ability to run certain tasks at scheduled intervals.
>>
>> For now, the solution I have implemented is as follows:
>>
>> I use a single ThreadPoolExecutor to run all tasks.
>> I use a separate ScheduledThreadPoolExecutor to manage scheduled tasks.
>> This executor does not run the tasks, instead it submits the tasks when
>> ready to the first ThreadPoolExecutor. This pool has only 1 thread
>> allocated.
>>
>> With this solution I am close to what I wanted, but I cannot avoid having
>> one thread (ScheduledThreadPoolExecutor) being idle most of the time.
>>
>> Is there a better way of achieving this?
>> Why is the scheduling function tied to the threadpool management? It would
>> seem to me that these are separate concerns.
>>
>> Thanks very much in advance for your help and advice.
>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
regards
 gustav trede
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100314/1416690b/attachment.html>


More information about the Concurrency-interest mailing list