[concurrency-interest] Sharing threads across executors

Dibyendu Majumdar concurrency-interest at majumdar.org.uk
Sun Mar 14 07:41:06 EDT 2010

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
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.


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

More information about the Concurrency-interest mailing list