-
Bug
-
Resolution: Fixed
-
P2
-
6
-
b93
-
generic
-
generic
-
Verified
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.
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.
- relates to
-
JDK-6431315 ThreadPoolExecutor.shutdownNow may hang ExecutorService.invokeAll
- Closed
-
JDK-6814989 STPE terminates when policy set to continue executing existing periodic tasks
- Closed
-
JDK-6522773 Decreasing ScheduledThreadPoolExecutor core pool size causes busy spin
- Closed