On Aug 25, 2016, at 2:55 PM, Andrew Eikum aeikum@codeweavers.com wrote:
Two catches with the macOS behavior: First, this implementation is much more expensive than one system call in a very frequently called function.
mach_absolute_time() isn't even a system call. It's implemented in user space. It reads the TSC from the CPU and applies adjustments read from the commpage. There's a potential for it to loop if the commpage is adjusted while it's running.
It's an open question whether fixing behavior on sleep is worth the cost. Second, the boot time has precision only to the nearest second. This could cause skew if the current time is updated in <~1 second intervals.
Actually, it will cause skew whenever the current time is updated by a delta that's not whole seconds.
Another issue is the race between sysctl() and gettimeofday(). If a time adjustment occurs between them, you'll get an incorrect result. This could be detected by checking the boot time again after gettimeofday() and repeating if it changed. Unfortunately, that adds even more overhead. (Actually, if we track the last known boot time in a static, we could only check it after and loop if it changed. That requires interlocked updating of the static, though, to make it thread safe.)
Unfortunately, I don't know a good solution. I think that it may be a bug that mach_absolute_time() doesn't count time spent sleeping, but that's of no comfort.
-Ken