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

Jonathan Baxter jbaxter at panscient.com
Tue May 17 20:43:52 EDT 2005


> 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.


Blocking behaviour can be very useful if you have interacting thread pools 
doing different kinds of work. Eg, thread pool a does work A, and then hands 
off to thread pool B that does work B. If the resource consumption patterns 
of work A and work B are very different (eg A waits on the network while B is 
computationally intensive), then it can be handy to have the workers in A 
block when handing off to a worker in B, so that the B work doesn't keep 
growing and chew up all the resources. 

Suffice it to say there are plenty of use cases, and that the old concurrent 
code supported this easily. It is somewhat surprising that that the new 
package makes this almost impossible to do in an elegant way. 


- Jonathan 

>
> --tim


More information about the Concurrency-interest mailing list