United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6247907 : Interruptions and ThreadPoolExecutor.runTask

Details
Type:
Bug
Submit Date:
2005-03-30
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2005-09-04
Component:
core-libs
OS:
generic
Sub-Component:
java.util.concurrent
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports

Sub Tasks

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



Hardware and Software, Engineered to Work Together