[concurrency-interest] Work-stealing ThreadPool

Doug Lea dl at cs.oswego.edu
Fri Apr 20 07:15:00 EDT 2012

On 04/19/12 11:14, Aleksey Shipilev wrote:
> Hi guys,
> 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?

To clarify what you are asking for.....
Both ForkJoinPool and ThreadPoolExecutor implement ExecutorService.
So if you'd don't want to expose any FJP or TPE methods, you
can just use these. If you'd like to further make non-ExecutorService
methods inaccessible even under downcast, then you'd instead want
a simple DelegatingExecutorService that relays only ExecutorService
methods; or possibly only a subset (for example, no shutdown()).
Is this what you are looking for?

If not, maybe the simplest addition is to add a factory method
in class Executors:
   ExecutorService workStealingExecutor() {
     return new ForkJoinPool();


More information about the Concurrency-interest mailing list