Maintenance Notice

The bugs.java.com site will be undergoing maintenance on 15th Dec 2017 21:00 PST to 16th Dec 2017 1:00 AM PST.
JDK-7035020 : ForkJoinPool.invoke may deadlock if parallelism = 1
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-04-08
  • Updated: 2011-06-08
  • Resolved: 2011-06-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 7
7 b140Fixed
Related Reports
Relates :  
Relates :  
Description
see discussion on concurrency-interest mailing list:
  http://cs.oswego.edu/pipermail/concurrency-interest/2011-April/007835.html

>> (http://stackoverflow.com/questions/5493399/forkjoinpool-parallelism-1-deadlock).
>> I'm pretty new to the Fork-Join framework, so this is probably an
>> obvious case of user-error, but I haven't been able to figure it out,
>> and thus far, none of the comments on that post have resolved the
>> issue either.
>>
>> I'm profiling a parallel algorithm over a range of thread-counts. My
>> tasks seem to work flawlessly if I create the ForkJoinPool with
>> parallelism>  1 (I've normally been running with 2-24 threads). But if
>> I create the ForkJoinPool with parallelism = 1, I see deadlocks after
>> an unpredictable number of iterations. And yes - setting parallelism =
>> 1 is a strange practice, but I want to accurately ascertain the
>> ohttp://cs.oswego.edu/pipermail/concurrency-interest/2011-April/007835.htmlverhead of the parallel implementation, which means comparing the
>> serial version and the parallel version run with a single thread.
>>
>> Below is a simple example that illustrates the issue I'm seeing. The
>> 'task' is a dummy iteration over a fixed array, divided recursively
>> into 16 subtasks. I chose this odd iteration simply to produce a
>> memory-bound workload - it's possible the task itself interacts oddly
>> with F-J or with JIT optimizations, but if so, I haven't been able to
>> tease out those interactions.
>>
>> If run with THREADS = 2 (or more), it runs reliably to completion, but
>> if run with THREADS = 1, it invariably deadlocks. After an
>> unpredictable number of iterations, the main loop hangs in
>> ForkJoinPool.invoke(), waiting in task.join(), and the worker thread
>> exits. (I've been running between 10000 and 50000 ITERATIONS,
>> depending on the host hardware)


This is the second bug byproduct of bad last-minute refoctoring of ForkJoinPool.awaitWork to offload some of the code into idleAwaitWork.

Along with the changes to fix the issue described above, this CR will be used to pull in two more minor changes in ForkJoinPool:
  1) Tolerate timing slop
  2) Fix mask growth comparison

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8fbd15bd6149
2011-04-08

EVALUATION see description.
2011-04-08