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

FutureTask bullet-proofing



    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Cannot Reproduce
    • Affects Version/s: 5.0
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:


      the jdk7 implementation of FutureTask has small correctness issues
      with state transition. If we look at innerRun

              void innerRun() {
                  if (!compareAndSetState(READY, RUNNING))

      //// Suppose cancel is invoked and returns here.

      //// At this point, isDone() returns true.

                  runner = Thread.currentThread();

      //// At this point, isDone() returns false.

                  if (getState() == RUNNING) { // recheck after setting thread

      we have a case where isDone() could return false after cancel() returns,
      even though isCancelled() returns true.

      It's the old problem of having state transitions recorded in two
      separate fields, when we can only update one of them atomically.
      We can make the races rarer, but I'm not sure we can eliminate them
      without moving all significant state into the one monotonically
      incremented CASable int.


      There's the other problem of interrupt delivery.
      It is not absolutely guaranteed that cancel(true) will indeed interrupt
      the task instead of its surrounding code.


      I believe both of the above problems by designing
      state transitions very carefully, without any additional overhead for
      the "normal" case of successful run().

      Perhaps there's a general principle here that any class which can
      be designed to have an ordered set of states with monotonically
      increasing transitions doesn't need locks, only CAS.

      I think we can solve the incorrectly delivered interrupt problem
      by (as usual) introducing a new state INTERRUPTING, with cancel()
      transitioning RUNNING -> INTERRUPTING -> CANCELLED.

      If the runner thread notices that state == INTERRUPTING, it must
      wait (via acquireShared) for the state to first advance to CANCELLED,
      before returning from run().

      If we keep track of whether an interrupt has been
      delivered, we can guarantee that it was delivered in a specific window,
      which would allow us to reconsider restoring interrupt state.

      In addition, I believe this can be done while supporting set() called
      independently, that is, not directly from run(), without any extra
      CAS state transitions in the normal case. See:

      6663476: FutureTask.get() may return null if set() is not called from run()


          Issue Links



              martin Martin Buchholz
              martin Martin Buchholz
              0 Vote for this issue
              1 Start watching this issue