[concurrency-interest] Question about signalWork() implementation in the Fork Join Pool

Doug Lea dl at cs.oswego.edu
Tue Jan 11 08:23:46 EST 2011

On 01/11/11 05:01, Antoine CHAMBILLE wrote:
> We are investigating dead lock issues in an application relying on the fork
> join pool. We are using the latest (December 2010) jsr166y release.

Sorry for problems. It would be very helpful if you could
send me (off-list) a stripped-down test case.

> We submit main tasks to the pool that process a number of items. Every n
> item the task creates a subtask in charge of those n items, register the
> subtask in a phaser,

Almost surely, you are encountering cases where the
total number of registered parties transiently exceeds
the pool's parallelism level (or internal target level).
Failure to accommodate this is a bug, that will be fixed:
the specs for FJ and Phaser don't say you cannot do this,
so it was wrong to assume programs would not do it.
(And we should not just add a disclaimer saying you cannot.)
Some soon-upcoming unrelated-looking improvements
that I'll post about separately address this problem.

(As Geert posted, as a temporary workaround, you can join
all subtasks rather than await the phaser, which evades
this issue.)

> So we have this question about the implementation of signalWork() in the
> fork join pool:
> Why is compare and swap failure allowed when maintaining the event count of
> the pool?

This is unrelated to your problem, but the answer is that,
under assumptions of maintaining minimal adequate parallelism,
it suffices for any signaller to wake up any worker. The "minimal
adequate parallelism" part is the issue here.


More information about the Concurrency-interest mailing list