[concurrency-interest] missed deadlines.

David Holmes dcholmes at optusnet.com.au
Thu Jul 6 23:15:37 EDT 2006

Dhanji R. Prasanna writes:
> Re auto-creation of pools, what is wrong with simply starting out with the
> max-intended size? After all there is no cost associated with idle threads
> there?

Sure there is - they use up OS threads, stack space etc. If they didn't we
wouldn't need thread pools we would just keep as many idle threads as we

> I would think that allowing for no cap on max threads is a *very* bad
> Or am I missing something else...

Having an unbounded maximum number of threads can be a bad idea if you have
an unbounded potential arrival rate for tasks. If the task arrival rate is
limited then so is the thread creation rate.

This is why ThreadPoolExecutor has its three-phase policy:
 - create new threads until coreSize is reached
 - then add to queue until queue is full
 - then create new threads until max is reached

Given the ability to allow core threads to timeout if idle in Java 6, this
gives you a lot of control over how the pool can grow and shrink.

ScheduledThreadPoolExecutor sets up the ThreadPoolExecutor queueing and
threading behaviour is a very specific way: the queue is effectively
unbounded so only coreSize comes into play. Given that, there is less
control over how ScheduledThreadPoolExecutor behaves.

Another possible enhancement to TPE is to set a low-water mark on the number
of core threads, so you never drop below that many when idle timeout is
enabled. That effectively breaks the core-pool into two parts, without the
queue coming into the picture, and so provides further policy flexibility.
For ScheduledThreadPoolExecutor this wouldn't help as the queue is what
provides the "delay until" behaviour.

David Holmes

More information about the Concurrency-interest mailing list