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

Ruslan Cheremin cheremin at gmail.com
Sun Feb 5 16:58:59 EST 2017


>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?


2017-02-06 0:44 GMT+03:00 Doug Lea <dl at cs.oswego.edu>:

> On 02/05/2017 11:33 AM, Ruslan Cheremin wrote:
>
> May be I miss something important, but I can't see in code how do
>> threads tries to help:
>>
>
> Oh, sorry to misinterpret your question. "External" threads
> (non-ForkJoinWorkerThreads) by design do not help normal pools,
> which makes them act like other ExecutorServices.
> (I was referring to "internal" threads in previous answer.)
> But they must help in commonPool, 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). But this is an add-on to
> ForkJoinPools that doesn't apply in general.
>
>
>
>> Is it because there is no way to find out to which FJPool given FJTask
>> was submitted?
>>
>>
> Yes, although that's more of a consequence rather than a cause.
>
> -Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170206/d616ea45/attachment.html>


More information about the Concurrency-interest mailing list