[concurrency-interest] Queue.add() vs Executor.exec()

Gregg Wonderly gregg at cytetech.com
Wed Feb 7 11:04:34 EST 2007

David Holmes wrote:
> Sorry for the late reply but I was on vacation and am still catching up.
> To be able to use the queue directly and have it "just work" either the
> queue needs to know about the pool, or else the pool must always have
> threads ready to read from the queue. Having the queue know about the pool
> means the queue is no longer just a BlockingQueue. Have the pool always
> ready to read from the queue means you don't have control of the number of
> threads that you generally would want (you could add heuristics to examine
> the length of the queue after take() returns and use that to add more
> threads etc - but that's messy).

Hi David, thanks for the followup.  In one of my queuing based thread pools, I 
use a multiplication factor to control the number of threads that are active. 
The enqueuing method basically does.

	if( curThreadCount < maxThreadCnt &&
			queueSize > curThreadCount * multFactor ) {

this makes it possible for a fairly simple management of the total number of 
threads running without an unnecessary ramp up of active threads.  The 
multFactor value is something that the application can tune based on its needs. 
  The main user of this thread pool is a database application which processes 
about 200 transactions per second into a handful of databases.  The db admin 
like the fact that they can tune the number of threads so that it is minimal 
based on the fairly predictable bandwidth through the system.  But, when they 
reboot the database server and things are backed up, it will ramp up to get the 
queue cleared out more quickly to make sure the database is in sync ASAP.

Gregg Wonderly

Gregg Wonderly

More information about the Concurrency-interest mailing list