[concurrency-interest] Work-stealing ThreadPool

√iktor Ҡlang viktor.klang at gmail.com
Thu Apr 19 13:29:05 EDT 2012

I really recommend to avoid the use of the ExecutorService interface,
it's just way too general/broad, placing a lot of burden on the underlying

That being said, I definitely think that splitting out the idea of
worker-local submission queues and work-stealing should be ripped out of
ForkJoinPool and then build ForkJoinPool on top of it.


On Thu, Apr 19, 2012 at 5:14 PM, Aleksey Shipilev <
aleksey.shipilev at gmail.com> 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?
> 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?
> -Aleksey.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120419/28e637c7/attachment.html>

More information about the Concurrency-interest mailing list