Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
>> where available and only use gettimeofday() as fallback solution
>> together with times(), ftime() and time().
> 
> Ok, I've tried and it's less good than expected. Using CLOCK_MONOTONIC
> absolutely kills efficiency. CLOCK_REALTIME is ok but it has no obvious
> benefits (microsecond resolution as given by gettimeofday() is probably
> sufficient).
> 
> The explanation AFAICT is that pthread_cond_timedwait() waits for
> absolute clock values as given by CLOCK_REALTIME.
> CLOCK_MONOTONIC gives other values (the man page says: "represents
> monotonic time since some unspecified starting point"). These values are
> probably "in the past" as seen from pthread_cond_timedwait(), which
> implies a busy loop of waiting for the GIL to be released, inside of
> being suspended gracefully until the timeout.

The CLOCK_MONOTONIC timer only guarantees that you
get an accurate time count. It doesn't maintain any relationship
to the wall clock time. For the case in question you don't need
the wall clock time, though. It's more important not have the
clock go backwards or be subject to jitter.

pthreads will default to use the real time clock. In order
to have them use the monotonic timer, you have to setup
a condition variable attribute: See the man-page for
pthread_condattr_setclock().

> I can still produce a patch with only CLOCK_REALTIME but I'm not sure
> it's worth the code complication.

Even if you don't use CLOCK_MONOTONIC you should still prefer
clock_gettime() over gettimeofday() simply because it's faster.
The resolution of both will likely be the same, unless the
hardware provides a more accurate timer than kernel ticks.

The code won't get more complicated if you refactor the time
querying logic into a separate function (which the compiler can then
inline as necessary).