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

Design troubles with Delayed and ScheduledThreadPoolExecutor


    • Type: Bug
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:


      Delayed implements Comparable<Delayed> but there is no way for a general Delayed implementation to fulfill the Comparable contract.

      A Delayed implementation has no choice but to compare
      this.getDelay() with other.getDelay()
      but because time keeps slipping into the future, two Delayed with exactly the same expiration time may compare differently, and compareTo is not necessarily anti-symmetric. It's fundamentally flaky.

      As a result, ScheduledThreadPoolExecutor cannot really fulfill its promise """Tasks scheduled for exactly the same execution time are enabled in first-in-first-out (FIFO) order of submission.""" The promise is problematic in any case because there is no way for a task submitter to specify the precise expiration time. But the implementation fails the weaker promise that a sequence of tasks with identical delays are scheduled in FIFO order.

      This affects users of STPE who use decorateTask and depend on the tasks being scheduled in FIFO order. The workaround is for decorateTask to retain a reference to the underlying ScheduledFutureTask and delegate to the compareTo method on that. (Any particular concrete implementation will be safe by simply comparing trigger times)

      Another problem is that getDelay() must call nanoTime to compute the delay, and this is unnecessarily expensive.




            • Assignee:
              martin Martin Buchholz
              martin Martin Buchholz
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: