[concurrency-interest] Work-stealing ThreadPool
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?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest