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

Martin Buchholz Martin.Buchholz at Sun.COM
Sat Jan 20 13:15:35 EST 2007


> Date: Fri, 19 Jan 2007 15:30:26 -0600
> From: Gregg Wonderly <gregg at cytetech.com>
> Subject: [concurrency-interest] Queue.add() vs Executor.exec()
> To: concurrency-interest <concurrency-interest at cs.oswego.edu>
> Message-ID: <45B13872.5000708 at cytetech.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> A couple of different times now, I've found myself coding queue.add() for a 
> queue owned by a ThreadPoolExecutor() instead of invoking an appropriate 
> ThreadPoolExecutor.exec(), etc. method.  This causes nothing to run, and it is a 
> bit frustrating to track down.  Historically, I guess part of the problem is 
> that the pooled executors I've used/written have only had one object and for 
> some reason by brain is making be consider the queue the similar object.
> 
> It seems that if the core thread pool size is non-zero that the associated 
> number of threads would be running and prepared to take whatever was put onto 
> the queue.

The number of threads might be zero even if core pool size is non-zero.
Did you call prestartAllCoreThreads() ?

STPE in fact uses

super.getQueue().add(task);

but it has control over the queue involved, unlike the more general TPE.

In general, adding directly to the queue is asking for trouble.
I dream of writing my own thread pool where the queue would not be
user-accessible.

A number of issues with TPE/STPE are being worked on for jdk7,
including some that leave the pool with less than the
desired number of threads.

6450200: ThreadPoolExecutor idling core threads don't terminate when
core pool size reduced
6450205: ThreadPoolExecutor does not replace throwing threads
6450207: ThreadPoolExecutor doesn't count throwing tasks as "completed"
6450211: ThreadPoolExecutor.afterExecute sees RuntimeExceptions, but not
Errors
6452337: ThreadPoolExecutor should prefer reusing idle threads
6454289: ScheduledThreadPoolExecutor spins while waiting for delayed
tasks after shutdown
6458339: ThreadPoolExecutor very slow to shut down for large poolSize
6458662: ThreadPoolExecutor poolSize might shrink below corePoolSize
after timeout

Martin

> Is there a good reason why it doesn't work in this way?
> 
> Gregg Wonderly


More information about the Concurrency-interest mailing list