Discussion:
[m-dev.] Thread Pools in the Mercury Java backend.
Paul Bone
11 years ago
Permalink
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.
--
Paul Bone
http://www.bone.id.au
Ian MacLarty
11 years ago
Permalink
Hi Paul,
Post by Paul Bone
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?

Cheers,
Ian.
Paul Bone
11 years ago
Permalink
Post by Ian MacLarty
Hi Paul,
Post by Paul Bone
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
Loading...