[concurrency-interest] ThreadPoolTask

David Holmes dcholmes at optusnet.com.au
Sat Jul 8 19:41:32 EDT 2006

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.

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.

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

More information about the Concurrency-interest mailing list