[concurrency-interest] ExecutorCompletionService

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Mon Jan 8 07:18:39 EST 2007


Hi Joe,

Thank you for your reply.

I have considered using CallerRunsPolicy. If it is the "caller" who is
submitting tasks to the ExecutorCompletionService, "keeping it busy"
with actual work (when there are no more free threads left in the
pool) has indeed a similar effect to what I am after. I fear however
that the "caller" thread would then be too long busy with the actual
work leaving worker threads idly waiting for input.

Thank you for your tip about WaitWhenBlocked. I wonder why it is not
included in the "official" package. This behaviour appears to me so
widely useful. This is why I suspect that the reason for not including
this class may be that, after all, there are some conceptual problems
with it.

Thanks
Peter


On 1/8/07, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> On 1/7/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
>
> >
> > I would like to use some kind of ThreadPool executor for execution
> > which blocks when the maximum number of threads in the pool is reached
> > and all threads are utilized.
> >
> > 1.) Is there such a ThreadPool executor implementation already
> > existing out there?
> >
> >
>
> CallerRunsPolicy is a close approximation.  Would that suffice?
>
> http://java.sun.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.CallerRunsPolicy.html
>
> Doug Lea provided a WaitWhenBlocked handler in his original thread pool:
>
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.java
>
>  You can try porting that if all else fails.
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>


More information about the Concurrency-interest mailing list