[m-dev.] Thread Pools in the Mercury Java backend.

Paul Bone paul at bone.id.au
Thu Oct 24 11:29:34 AEDT 2013


On Thu, Oct 24, 2013 at 10:00:49AM +1100, Ian MacLarty wrote:
> Hi Paul,
> 
> On Thu, Oct 24, 2013 at 12:22 AM, Paul Bone <paul at bone.id.au> wrote:
> >
> > Hi.
> >
> > I've made some notes on my idea for implementing thread pooling for the
> > Mercury java backend.
> >
> > https://github.com/Mercury-Language/discussions/blob/master/parallelism_and_java/2013-10-23_thread-pools.txt
> >
> > If anyone has any comments I'd appriciate them.
> >
> 
> Have you considered using the supplied thread pool system in
> java.util.concurrent?
> 

We tried this for ODASE and found that ThreadPoolExecutor does not behave
the way we wanted/needed it to.

Regarding ThreadPoolExecutor
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html

     If there are more than corePoolSize but less than maximumPoolSize
     threads running, a new thread will be created only if the queue is
     full.

To put this in context, the ThreadPoolExecutor allows the programmer to
choose different queues, if they choose a bounded queue then new threads are
created when the queue becomes full.  If the queue isn't full, or is
unbounded, then the thread pool always has a fixed size.

This is not the behaviour I want.  I want to create new threads in the case
that that less than P of the existing threads are idle, regardless of the
fullness of the queue.

I'm not against using the existing code, so if anyone thinks that the
behaviour of ThreadPoolExecutor might be better I'd like to know why.

Thanks for your feedback.


-- 
Paul Bone
http://www.bone.id.au



More information about the developers mailing list