Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6247907

Interruptions and ThreadPoolExecutor.runTask

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 6
    • 6
    • core-libs

      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

            martin Martin Buchholz
            martin Martin Buchholz
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: