[concurrency-interest] Fwd: ThreadPoolTask

Peter Veentjer alarmnummer at gmail.com
Sun Jul 9 06:49:52 EDT 2006

---------- Forwarded message ----------
From: Peter Veentjer <alarmnummer at gmail.com>
Date: Jul 9, 2006 12:44 PM
Subject: Re: [concurrency-interest] ThreadPoolTask
To: "Dhanji R. Prasanna" <dhanji at gmail.com>

On 7/9/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> On 7/9/06, Peter Veentjer <alarmnummer at gmail.com> wrote:
> > 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.
> Sure you can. setCorePoolSize() and setMaximumPoolSize() can be called any
> time after construction, along with prestartCoreThread() to force the pool
> to change size dynamically.
> David's suggestion makes a lot of sense; simply let your queue feed the same
> task over and over.
If the queues returns the same value over and over, Davids idea works.
But if a task is responsible for resubmitting itself, you need to have
at least as many tasks as there are threads and this is complex. That
is why increasing the poolsize with this approach has no meaning
because there are no tasks the extra threads can execute.

> I would also say that setting a starting corePoolSize of 0 is pointless, and
> probably confusing to a maintainer. The ThreadPoolExecutor does not create
> the first thread until it is needed anyway, so you have not gained anything
> with a starting size of 0. If you want your executor to drop to 0 threads at
> a mature point in its lifecycle, just release it to the gc and create a new
> one when needed. Otherwise I dont see the point of (effectively) using
> ThreadPoolExecutor as a state machine for your app.
> > The problem with a tasks that loops is that the executing thread in
> > the executor is 'lost' forever.
> But there is only ever one task that he wants to repeat, if I understood
> correctly, so what is the problem with running it in the same thread
> forever?
What about shutting down. I want to shutdown my thread-engines in a
controlled and predicatable manner and with a 'while(true){....}' loop
this isn't possible. Ofcourse you can add some kind of flag, but this
places an extra responsibility with the task. So a runnable that loops
for ever imho is a bad approach especially if there are better
alternatives like the Repeater.

The Repeater uses a WaitableReference: this is a synchronisation
structure where a threads blocks if it wants to retrieve a reference
and there is none. And if there is one. the reference is returned. A
queue that keeps returning some value (after a value has been added)
or block if none is available, has the same behaviour.

So in essence they are not that different. But with a Repeater I have
some control I don't have with Executors like preventing concurrent
execution of different runnables.

> Repeat = sequential, resubmit/multiple submit = concurrent. Either way the
> problem does not require a special delegating executor (unless this is
> simply an abstraction facade for your app).
> Maybe Im not seeing the issue...

More information about the Concurrency-interest mailing list