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

ThreadPoolExecutor.getTaskCount should abandon monotonicity guarantee

XMLWordPrintable

      getTaskCount might possibly see a decrease if your timing is
      very bad, if called just before a worker runlock is unlocked,
      and then again just after. Similarly, a task that has just been
      removed from the workQueue but has not yet been started by a worker
      will not be counted.

      Probably we should just remove the "does not ever decrease".

          /**
           * Returns the approximate total number of tasks that have ever been
           * scheduled for execution. Because the states of tasks and
           * threads may change dynamically during computation, the returned
           * value is only an approximation, but one that does not ever
           * decrease across successive calls.
           *
           * @return the number of tasks
           */
          public long getTaskCount() {

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

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: