[concurrency-interest] Work-stealing ThreadPool
aleksey.shipilev at gmail.com
Thu Apr 19 11:14:59 EDT 2012
There are multiple cases now when people are choosing ForkJoinPool over
regular ThreadPoolExecutor because of improved submission throughput and
work balancing. Can we embrace this fact and do proper isolation in API
for this cases?
I'm thinking public class j.u.c.WorkStealingExecutor implementing
ExecutorService, but delegating directly to ForkJoinPool. If that is
added to JDK7/JDK8, we can properly isolate these customers from
exposing FJP underneath. Moreover, after this API is exposed, we can
gradually replace FJP delegation with independent work-stealing
executor, if ties with FJP will bother anyone.
Are there any troubles with this proposal I missed?
More information about the Concurrency-interest