Commits on Sep 24, 2019

1. Avoid use of global AtomicLong for ScheduledFutureTask ids …

   Motivation
   
   Currently a static AtomicLong is used to allocate a unique id whenever a
   task is scheduled to any event loop. This could be a source of
   contention if delayed tasks are scheduled at a high frequency and can be
   easily avoided by having a non-volatile id counter per queue.
   
   Modifications
   
   - Replace static AtomicLong ScheduledFutureTask#nextTaskId with a long
   field in AbstractScheduledExecutorService
   - Set ScheduledFutureTask#id based on this when adding the task to the
   queue (in event loop) instead of at construction time
   - Add simple benchmark
   
   Result
   
   Less contention / cache-miss possibility when scheduling future tasks
   
   Before:
   
   Benchmark      (num)   Mode  Cnt    Score    Error  Units
   scheduleLots  100000  thrpt   20  346.008 ± 21.931  ops/s
   
   Benchmark      (num)   Mode  Cnt    Score    Error  Units
   scheduleLots  100000  thrpt   20  654.824 ± 22.064  ops/s

   

   njhill committed Sep 24, 2019
   Copy the full SHA

   ae2113e View commit details

   Browse the repository at this point in the history