[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Updated docs on NTP segment management

From: Gary E. Miller
Subject: Re: [gpsd-dev] Updated docs on NTP segment management
Date: Wed, 18 Feb 2015 00:29:48 -0800

Yo Hal!

On Tue, 17 Feb 2015 23:26:02 -0800
Hal Murray <address@hidden> wrote:

> > I thought that there was a time when the two sides did some sort of
> > "handshake" thru the SHM segment, and that was apparently useful to
> > let each side know the other side was paying attention. 
> The current SHM stuff requires read/write by ntpd.
> I think that making the client side of SHM read only is enough of a
> change that I've been assuming we would make a new interface.  It
> might be possible to make it somewhat backwards compatible, but that
> would be more in name than spirit.

I see no reason to make it not writeable by the client.  So no need,
yet, for a compatibility break.

> For the record, here is a recipe for a SHM handshake where the client
> can be read only...

OK, but why bother?

> It takes 2 counters.  Call them X and Y.
> The writer bumps X, updates the data, then copies the new X to Y.
> The reader grabs Y, grabs the data, then grabs X.  If X and Y differ,
> the data was being updated.  The reader has to compare Y with the
> previous value to ignore stale samples.
> It's important that the reader and writer operate on X and Y in the
> opposite order.

Sadly read order can not be fixed on many architectures, like x86.  

So X and Y may have been flushed by the cache to main RAM, but not the
data it is guarding.

If a scheme like this could work the Linux kernel guys would have done it
a long time ago.  They have tried but always come back to locks and
things like RCU.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

reply via email to

[Prev in Thread] Current Thread [Next in Thread]