[concurrency-interest] ForkJoinPool not designed for nested Java 8streams.parallel().forEach( ... )

Christian Fries email at christian-fries.de
Mon May 5 17:54:40 EDT 2014


Dear Aleksey.

If run my code in the deadlock situation, wait for the deadlock, then check every thread (suspending all of them) you see that 5 threads are blocked at the Semaphore. And 5 others have reached the inner loop and are blocked at an awaitJoin of a ForkJoinTask of the inner loop.

My (maybe to light hearted) conclusion is that a task of the inner loop waits for a task of any blocked outer loop. Why and how is this dependence introduced?! (And given your solution: why is it solved by your code ;-)

Best
Christian


Am 05.05.2014 um 23:04 schrieb Aleksey Shipilev <aleksey.shipilev at oracle.com>:

> On 05/06/2014 12:40 AM, Christian Fries wrote:
>> It appears to me as if nested Java 8 parallel streams will create a
>> very subtle „implicit coupling“ between the tasks submitted to the
>> common pool, because tasks of an inner loop are joined with tasks on
>> an outer loop.
> 
> What coupling are you talking about now? In my mental model, starting
> the parallel() computation from the parallel() computation is "just"
> invoking the FJTask from the already executing one, and that is just
> forking-joining on a new task. Joining on inner FJTask will assist
> executing it. Which means that FJThreads executing the outer loop will
> assist executing the inner loop if they are "joining" on inner loop
> computations.
> 
>> So maybe the problem is to have a common FJP at all?
>> 
>> I still have the impression that the line ((t =
>> Thread.currentThread()) instanceof ForkJoinWorkerThread) is not
>> correct in the case of a nested loop.
> 
> Why? It checks if we are within the FJP and may proceed to awaitJoin to
> *help* other tasks.
> 
> -Aleksey.




More information about the Concurrency-interest mailing list