Re: Detecting shift of CLOCK_REALTIME with clock_nanosleep (again)

Scot Salmon
2012-12-19T20:43:50Z

John Stultz wrote on 11/15/2012 02:53:56 PM:
> On 11/15/2012 11:28 AM, Scot Salmon wrote:
> > Thomas Gleixner wrote on 10/31/2012 03:08:45 PM:
> > > What you are concerned about is keeping the machines in sync on a
> > > common global timeline. Though your more fundamental requirement is
> > > that you get the wakeup on each machine in the given cycle time. The
> > > global synchronization mechanism just adjusts that local periodic
> > > schedule.
> > [...]
> > > What you really want is an atomic readout facility for
> > > CLOCK_MONOTONIC and CLOCK_REALTIME. That allows you to align the
> > > CLOCK_MONOTONIC based timer with the global CLOCK_REALTIME based
> > > time line and in the event that the CLOCK_REALTIME clock was set
> > > and jumped forward/backward you have full software control over
> > > the aligning mechanism including the ability to do sanity checking.
> > This works for me. We discussed it on IRC and agreed on "something
> > like clock_gettime2(id, id, *t1, *t2) with a sanity check on the ids,
> > that allows us other combinations than MONO/REAL as well".
> Yea, there's been a few times that folks have brought up the need, and
> this sort of interface is probably the best way to go.

I spent a few days working on clock_gettime2 this week, and I've hit a
snag. I tried an implementation where I look up the two kclocks from
their clockid and call kc1->clock_get() and kc2->clock_get() with the
timekeeping data locked. The problem is, if id1 and id2 are the obvious
choices of MONO and REAL, their clock_get's end up calling
timekeeping_get_ns which samples the clock source synchronously, so I
get two discrete samples of the underlying clock even if I have locked
out any changes to the timekeeping data.

This implementation does work for the _COARSE clockid variants, but it
seems from some quick checks that those aren't going to be suitable for
my needs (too coarse).

Since there's nothing I can do to keep the underlying hardware clock
source from ticking, it seems like my options are pretty limited. I
can't do anything that will lead to two samples of the clock source.
All I can think of is to sample it for the first clockid, then derive
the value for the second from the first, for example by offsetting a
CLOCK_MONOTONIC read with tk->offs_real and returning that as the
synchronized value for CLOCK_REALTIME. Which isn't incredibly horrible
for those two, but making it general would get very ugly.

Any thoughts?

-Scot