JDK-6247907 : Interruptions and ThreadPoolExecutor.runTask
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Priority: P4
  • Affected Version: 6
  • OS: generic
  • CPU: generic
  • Submit Date: 2005-03-30
  • Updated Date: 2010-04-02
  • Resolved Date: 2005-09-04
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 6
6 b51Resolved
Description
Tim Peierls wrote:

Doug Lea wrote:

>>>> We don't want an interrupt occurring before the task starts to cancel 
>>>> the task, since that interrupt might have been targeted to the
>>>> previous task run by that thread. This would be much much worse.
>>>> 
>>>> So instead, the runState == STOP test is taken as a commit point. The 
>>>> down side is that there is a window during which our best efforts to
>>>> stop things fail. I don't think there is a solution to this. Or does
>>>> anyone see one?


David Holmes wrote:

>> Surely if you invoke Thread.interrupted before checking the runState you
>> will have cleared any prior interrupt that may have been targeted at
>> the previous task? Any subsequent interrupt is either due to the
>> shutdownNow or specific cancellation of this task.



Just to make sure we're talking about the same thing -- I was asking
whether the current TPE.runTask(),

     runLock.lock();
     try {
         // Abort now if immediate cancel.  Otherwise, we have
         // committed to run this task.
         if (runState == STOP)
             return;

         Thread.interrupted(); // clear interrupt status on entry

         ... run task ...
     } finally {
         runLock.unlock();
     }

might be improved (perhaps only slightly) as follows:

     runLock.lock();
     try {
         Thread.interrupted(); // clear interrupt status on entry

         // Abort now if immediate cancel.  Otherwise, we have
         // committed to run this task.
         if (runState == STOP)
             return;

         ... run task ...
     } finally {
         runLock.unlock();
     }

--tim

-------------------------------------------------
David Holmes replied:

Yep that is still what I am referring to. The call to interrupted should
clear any outstanding interrupts for the previous task, or a current
interrupt due to a shutdownNow. In the latter case the testing of runState
covers things so it is okay to clear the interrupt.

David
-------------------------------------------------
Doug Lea responded:

You are right. Thanks! Will do.



###@###.### 2005-03-30 09:25:33 GMT

Comments
EVALUATION Looks good. ###@###.### 2005-03-30 09:25:34 GMT
2005-03-30

SUGGESTED FIX --- /u/martin/src/jsr166/cvs/src/main/java/util/concurrent/ThreadPoolExecutor.java 2005-03-29 20:26:49.868876000 -0800 +++ /u/martin/ws/jsr166/src/share/classes/java/util/concurrent/ThreadPoolExecutor.java 2005-03-04 20:19:06.067269000 -0800 @@ -649,12 +649,12 @@ final ReentrantLock runLock = this.runLock; runLock.lock(); try { - Thread.interrupted(); // clear interrupt status on entry // Abort now if immediate cancel. Otherwise, we have // committed to run this task. if (runState == STOP) return; + Thread.interrupted(); // clear interrupt status on entry boolean ran = false; beforeExecute(thread, task); try { ###@###.### 2005-03-30 09:25:34 GMT
2005-03-30