[concurrency-interest] ThreadPoolTask

Peter Veentjer alarmnummer at gmail.com
Sun Jul 9 04:39:28 EDT 2006


On 7/9/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> I must be missing something. If you want to submit the same task multiple
> times then submit the same task multiple times. If you want a task to repeat
> then either code it so it repeats, or resubmits itself or use a periodic
> task if there is a repeat interval.
The problem with resubmitting a task is that you can't increase the
size of the pool.
The problem with a tasks that loops is that the executing thread in
the executor is 'lost' forever.

The executor is not made for continuous (multithreaded) execution of a
single task and that is the reason why I made the Repeater.

>
> I think your always full queue is relying on current implementation that
> favours passing a queued task when creating a new thread above coreSize.
> This behaviour has been changed for Mustang.
>
> Of course once a thread has been created and given its initial task in some
> way then that thread will take from the queue and forever repeat the task
> handed out by the queue. The trick here is to get the threads started.
>
> Your requirement that the task must be passed in the constructor (presumably
> the pool constructor) means you need to prime the pool somehow to start the
> threads and have them take from the queue. I don't think you can do that
> without performing the required number of execute() operations.
>
> Further, I just spotted an apparent bug if the coreSize is zero.
>
> But why set core to zero anyway? How do you expect to define how many
> threads should be processing this task? And how would the pool ever shrink
> as no thread would ever be idle. Soundsl like using a queue that always
> returns your task, and pre-starting core threads would do what you want.
>
> Cheers,
> David Holmes
>
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Jean
> > Morissette
> > Sent: Sunday, 9 July 2006 4:01 AM
> > To: concurrency-interest at cs.oswego.edu
> > Subject: [concurrency-interest] ThreadPoolTask
> >
> >
> > Hi,
> >
> > I need to create a pool of threads that run only one thead-safe task
> > forever.  The task, which is a Runnable, must be passed in the
> > constructor.  Also, the thread pool size should be resizable and have
> > some lifecycling capabilities.
> >
> > I was thinking to create it on top of ThreadPoolExecutor, by setting
> > corePoolSize to zero and by using a custom queue that is always full
> > of the same task instance. So, by adjusting maxPoolSize, we can set
> > the number of threads executing the task. Here are some code to show
> > what I mean.
> >
> > public class ThreadPoolTask {
> >
> >       private ThreadPoolExecutor executor;
> >
> >       public ThreadPoolTask(Runnable task) {
> >               this.executor = new ThreadPoolExecutor(0, 1, 1,
> > TimeUnit.SECONDS,
> > new FullQueue(task));
> >       }
> >
> >       public void setPoolSize(int size) {
> >               executor.setMaximumPoolSize(size);
> >       }
> >
> >       public int getPoolSize() {
> >               return executor.getMaximumPoolSize();
> >       }
> >
> >       private static class FullQueue implements BlockingQueue {
> >               // ...
> >       }
> > }
> >
> > What do you think?  Is there a more elegant way to implement my
> > requirements?
> >
> > Thanks,
> > Jean
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> 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