[concurrency-interest] MaximumPoolSize not used with unboundedqueues

David Holmes dcholmes at optusnet.com.au
Fri Mar 31 20:39:02 EST 2006


A similar issue was discussed not that long ago, so please also see the

Basically the design for ThreadPoolExecutor is to handle an incoming task as

1. create (or use if prestarted) core thread if less than coreMax; else
2. offer to queue; else (if queue is bounded and full)
3. create pool thread if less than max; else
4. invoke RejectedExecutionHandler

The basic design philosophy is that the core exists to handle the normal
workload. The queue exists to buffer tasks that come in quicker than the
pool can handle. You bound the queue if you need to ensure the outstanding
tasks don't grow without limit and allow the pool to grow beyond core to try
and catch up with the (hopefully temporary) overload. You typically set a
timeout so the extra threads die out when things are quiet again.

If you have an unbounded queue then steps 3 and 4 never come into play. If
you have an unbounded queue but wanted to expand the pool size too, then how
would you have that decision be made? Would you add to the queue and add a
new thread? That would be a possibility. However this is no way to customize
this behaviour in ThreadPoolExecutor.

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of david
  Sent: Thursday, 30 March 2006 11:19 PM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] MaximumPoolSize not used with


  I am using a threadPoolExecutor with a PriorityBlockingQueue (not

  I made the choice of an unbouded queue to be able to resize the queue
dynamically using the setMaxCapacity() without having to kill my executor or
my queue.

  I don't see why the MaximumPoolSize wouldn't be used in that case.

  If I set 2 thread in the corePool and 5 as maximumPool, only my 2 threads
of the core will be spawned. Then for further tasks coming, as long as the
two first threads are busy, the queue will be used to store the incoming
tasks. Without even trying to spawn new threads as specified on the

  Why such a limit ?

  Is there any way to bypass this ? Is there a valid reason of not using
temporary threads with an unlimited queue ???

  Thanks for ur inputs :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060331/bbc9a132/attachment.html

More information about the Concurrency-interest mailing list