[concurrency-interest] ForkJoinTask.externalAwaitDone() co-operates only with commonPool?

Doug Lea dl at cs.oswego.edu
Mon Feb 6 08:00:07 EST 2017

On 02/05/2017 04:58 PM, Ruslan Cheremin wrote:
>>mainly because the commonPool might not have any workers, due to
> system-wide policies. Doing it this way enables parallelStreams etc
> to still work in managed environments (although with no possibility of
> speedup)
> Oh, so it is for purposes of fallback/graceful degradation. Very
> interesting, thank you for pointing this out, Doug.
> But doesn't it put additional overhead on commonPool? I mean, every time
> I use .join() on non-commonPool tasks, current thread tries to steal
> task back from commonPool workQueue(s), which is never succeeded, but
> probably do some cache trashing anyway?

You can concoct scenarios where this could have a measurable impact,
but it almost never does. In the usual case where
the commonPool is quiescent but your user pool is not,
it amounts to a table lookup on a variable that is not changing,
adding only a cache line or two to per-thread footprint.


More information about the Concurrency-interest mailing list