[concurrency-interest] CHM.compute restrictions

Doug Lea dl at cs.oswego.edu
Wed Aug 8 08:35:39 EDT 2018

On 08/07/2018 12:19 PM, Peter Levart via Concurrency-interest wrote:

> On 08/07/2018 06:12 PM, Peter Levart wrote:
>> To avoid that, outer and inner tasks should not share the same
>> ForkJoinPool.

This might happen to work. But the underlying issue is that the call to
CHM.compute causes a nested call to compute that may modify the same
map. This is is specifically disallowed for Map.compute,

The spec says "should not" vs "must not" because there are special cases
in which it may be OK. And also cases in which it is trapped as an
exception. Which does not happen here because the logically nested call
occurs in another thread, which evades CHM checks. Some execution
schedules will encounter lockup, some won't.

A better fix to the program would be to not nest parallelism within the
compute method itself (forcing reservation), but instead in another
method that finally sets the entry with result of call. Possibly using
CHM.replace for atomicity.


More information about the Concurrency-interest mailing list