JDK-6440728 : ThreadPoolExecutor can fail to execute successfully submitted tasks as specified
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-06-20
  • Updated: 2017-05-16
  • Resolved: 2006-07-22
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 Availability Release.

To download the current JDK release, click here.
JDK 6
6 b93Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
The basic contract of TPE.execute() is that the submitted task will either be executed or else rejected if execution is not possible due to the state of the TPE; further in the case of shutdownNow() being invoked any task not executed should be returned in the List returned by that method.

There are a number of situations where this basic contract can be violated:

1. The addIfUnderMaximumPoolSize method gives preference to executing an existing queued task over the one submitted to execute(). However, if there is a failure when adding a new thread in this case, the previously queued task will be dropped and never executed.

2. If core threads are allowed to timeout in a ScheduledThreadPoolExecutor, then if the delay of the tasks being scheduled is greater than the keepAlive time of the core threads, then all core threads could terminate and there will be no threads to process the scheduled tasks once their delay expires.

3. If shutdownNow() is called around the same time that a task is submitted to execute() then it is possible for the submitted task to be added to the workQueue after shutdownNow() has created its list of unexecuted tasks and the pool threads have all terminated. The submitted task will then languish in the workQueue, never to be executed.

4. Similar to #3 but the opposite problem, if the submitted task is placed in the workQueue, it is possible for the task to be included in the List returned by shutdownNow() but still be executed by a pool thread that was preempted just prior to taking a task from the workQueue and which won't see that the pool has been shutdown already. This could result in the application executing the task twice.

Comments
EVALUATION These issues were identified by the jsr-166 expert group and a fix is being provided through Doug Lea. Problems #1 and #2 have specific targeted fixes, while #3 and #4 require reworking of the shutdown protocol through more careful management of the TPE state transitions and by ensuring the workQueue is drained as part of shutdownNow() (which is the way some people expect shutdownNow() to operate, though the existing implementation did not).
20-06-2006