Replace `Time.now` with new monotonic clock

[jdantonio]

Monotonic clock support was added in PRs #253 and #254. There are numerous placers where we use Time.now in our code. We should replace as many of those as possible with monotonic clocks. The current clock_time implementation within Condition should be moved to the Concurrent namespace and made public. Each of the following classes should then be updated, if possible:

• Agent (used for observation)
• Condition
• RubyThreadPoolExecutor
• RubyThreadPoolWorker
• TimerSet
• IVar (used for observation)
• ScheduledTask
• [x] TimerTask (uses timer for scheduling and Time.now for observation

[pitr-ch]

I would treat this as a bug, it may cause ugly/hard-to-find bugs.

[jdantonio]

Unless there is some way to make guarantees on systems without a monotonic clock, I don't see that we can consider it a bug. It's a limitation in Ruby that we can't do anything about. I plan to write extensive documentation explaining possible clock problems and attach that documentation to all abstractions within this library that use the clock, but I think that's the best we can do.

I'm open to suggestions for alternate solutions.

[pitr-ch]

We may need to do more C coding :/ borrowing ideas from https://github.com/copiousfreetime/hitimes AFAIK the gem uses monotonic clock.

[jdantonio]

Writing C code to do this will only help a limited audience. It would provide better support for MRI 1.9.3 and 2.0, but only when the C extension gem is installed. It won't help Rubinius users. Support for Ruby 1.9.3 has ended so we're mostly talking about MRI 2.0 and Rubinius. As much as I would like to offer a perfect solution, this is a problem that eventually goes away as people upgrade to the newer versions of Ruby.

It should be fairly easy to copy the C code from MRI and create a pure-C fallback so I'll look into that. But we'll still have to document that some users may have problems in certain edge cases.

[pitr-ch]

You are right I forgot that we need also a pure-Ruby solution. In that case we could do a slow but correct implementation in pure-Ruby. Pseudo implementation follows

synchronize do
  @correction ||= 0 # compensating any back time shifts
  now = Time.now.to_f
  corrected_now = now + @correction
  if @last_time < corrected_now
    return @last_time = corrected_now 
  else
    @correction += @last_time - corrected_now + 0.000_001
    return @last_time = @correction + now
  end
end

and possibly warn users to use c extensions on old MRI version.

[jdantonio]

Thanks for the suggestion!

[jdantonio]

@pitr-ch I think that for now I'm going to hold off on created a C implementation. I've implemented a pure-Ruby version based on your suggestion and run some timing tests. The Ruby version is significantly slower, as would be expected. But the number of users that would benefit from a C implementation is fairly small and will continue to get smaller as more MRI users upgrade. The C implementation seems to be very operating-system dependent. I'm not sure it's worth the added complexity. Nothing would prevent us from adding that optimization in the future.