[concurrency-interest] Work-stealing ThreadPool

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Fri Apr 20 00:58:41 EDT 2012


Are there many OSS frameworks that use FJ in different ways to understand
these requirements ? The
wide adoption of these ideas could form a better sample space. Now it seems
that only specialized framework
developers use them.

I might be wrong because we don't have colleagues who are aware of some of
these advanced ideas.


On Thu, Apr 19, 2012 at 8:44 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120420/597edc97/attachment.html>

More information about the Concurrency-interest mailing list