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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
