Jeanne Boyarsky wrote:
As a point of interest, the Stream API sets off two times the number of threads in parallel than you have cores. On my machine, I have 8 cores and get 16 parallel operations. The following shows this. IF I remove the +1 from the code, it runs to completion. All 16 threads hit the cyclic carrier and then the barrier releases them all at once. However with 17 threads, the last one gets stuck and the program hangs.
@Jeanne
No, you don't have 2 * Runtime.getRuntime().availableProcessors() threads (at least not by default).
You have Runtime.getRuntime().availableProcessors() - 1 ForkJoinPool.commonPool worker threads plus the main
thread (which makes 8 threads in total in your case).
Try "cores * 3" instead of "cores * 2 + 1" and
you should see that it works, whereas "cores + 1" should hang the program. That's the behavior on my hexa-core machine at least.
What seems to be really happening when the number of ints is "n * cores + 1" (where n = 1, 2, 3, ...) is that the commonPool worker thread that gets assigned the task of processing the additional int is blocked at the CyclicBarrier while the main thread which has forked (directly or indirectly) the now blocked commonPool task is waiting for that task to signal completion (which won't happen, of course).