[concurrency-interest] Sharing threads across executors

Ben Manes ben_manes at yahoo.com
Mon Mar 15 14:45:40 EDT 2010


You can use a single-threaded ScheduledThreadPoolExecutor that delegates the execution to a dynamically-sized ThreadPoolExecutor.  This worked well for me, given that I was still on JDK5 where I couldn't leverage the JDK6's additional threadpool features.




________________________________
From: Dibyendu Majumdar <concurrency-interest at majumdar.org.uk>
To: concurrency-interest at cs.oswego.edu
Sent: Sun, March 14, 2010 4:41:06 AM
Subject: Re: [concurrency-interest] Sharing threads across executors


Hi Enno,

Thanks for the reply.


On 14 March 2010 03:05, Enno Shioji <eshioji at gmail.com> wrote:
>
>
>>You can use ScheduledThreadPoolExecutor as a ThreadPoolExecutor, so
>>there is no need to let it submit tasks to another ThreadPoolExecutor
>>(the queue implementation will be DelayQueue though).
>
>
>

As I understand it, ScheduledThreadPoolExecutor uses a fixed size pool
of threads, so if I used this, I would have to predefine the number of threads to
the maximum I would ever need. I am trying to have a more dynamic solution
where the number of threads grow dynamically when there is load, but also
get reduced when things are quiet.
 
>Also, if you mix the queue (have different kinds of tasks in the
>>queue), the queuing time becomes more difficult to predict, because
>>there will be potentially long-running tasks and short-running tasks
>>in there - that can lead to a headache.
>
>

True. My understanding is that the ThreadPoolExecutor will acquire new threads
rather than queueing up tasks when a SynchronousQueue is used (such as
when using Executors.newCachedThreadPool()). So queueing time should be
minimal. But this can potentially lead to many threads being created ...

I have some tasks that should absolutely never be blocked, because if 
these get blocked, the system will grind to a halt. Other types of tasks
are less critical, and can be queued with some negative impact on clients.
It does look like I cannot balance these two requirement with the goal of 
having a single threadpool as there is no concept of prioritizing of tasks.

Regards

Dibyendu


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100315/3ef99908/attachment.html>


More information about the Concurrency-interest mailing list