[concurrency-interest] PooledExecutor vs java.util.concurrent
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