On 05/19/2017 11:07 AM, David Holmes wrote:

They have to be as there are three cases:

1. Relative wait using CLOCK_MONOTONIC
2. Relative wait using gettimeofday()
3. Absolute wait using gettimeofday()

Please consider something like:

   if (_use_clock_monotonic_condattr  && !isAbsolute) { // Why aren't we using 
this when not isAbsolute is set?
                                // I suggest removing that check from this if 
and use monotonic for that also.

Absolute waits have to be based on wall-clock time and follow any adjustments made to wall clock time. In contrast relative waits should never be affected by wall-clock time adjustments hence the use of CLOCK_MONOTONIC when available.

In Java the relative timed-waits are:
- Thread.sleep(ms)
- Object.wait(ms)/wait(ms,ns)
- LockSupport.parkNanos(ns) (and all the j.u.c blocking methods built on top of 

While the only absolute timed-wait we have is the LockSupport.parkUntil 

Hope that clarifies things.

Yes thanks!

But you can still re-factoring to something similar to what I suggested and two 
of the calculation should be the same just ns vs us, correct?
Leaving the if statement with the "!isAbsolute" check, in my head calc_time is 
something like:

void calc_time(...) {
  if (isAbsolute) {
  } else {

I do not see a problem with this, only better readability?



      struct timespec now;
      int status = _clock_gettime(CLOCK_MONOTONIC, &now);
      assert_status(status == 0, status, "clock_gettime");
      calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_nsec, 
   } else {
      struct timeval now;
      int status = gettimeofday(&now, NULL);
      assert(status == 0, "gettimeofday");
      calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_usec, 

Thanks for fixing this!


Reply via email to