[concurrency-interest] PooledExecutor vs java.util.concurrent

Tim Peierls tim at peierls.net
Tue May 17 20:31:03 EDT 2005

Jonathan Baxter wrote:
>>>> ExecutorService exec = new ThreadPoolExecutor(1, 10, 1,
>>>>          TimeUnit.MINUTES, new SynchronousQueue<Runnable>());
> But ThreadPoolExecutor uses the the offer method not the put method of the 
> BlockingQueue, and according to the BlockingQueue documentation, offer 
> returns immediately if an element cannot be added to the queue. So it doesn't 
> seem to matter what kind of BlockingQueue you specify (Synchronous or 
> otherwise), you're never going to get blocking behaviour. 

Yup, ignore my previous mail. As you say, while pool is at max, it will 
reject further tasks.

I suppose you could extend SynchronousQueue with an offer method that does 
block. But I don't understand why you *want* to block the calling thread. 
You could use CallerRunsPolicy to run the rejected task in the calling 
thread, which would be like blocking, except it would get some work done. 
You could use the default policy and catch RejectedExcutionException, do 
some work, and try again. Both of these seem preferable to just sitting 
there indefinitely waiting for the pool to open up.


More information about the Concurrency-interest mailing list