Re: [gpsd-dev] SHM refclock improvements

[Gary E. Miller]

Yo Hal!

On Tue, 28 Aug 2012 15:01:51 -0700
Hal Murray <address@hidden> wrote:

> > How will we be able to know if an ntpd is capable of the new SHM
> > mode??
> 
> Plan one is to release a new ntpd that handles the new mode, wait for
> it to get widely distributed, then release a new gpsd that takes
> advantage of it. That's likely to take a long time.

gpsd is still fighting with major distros not updated to gpsd 3.x yet.
Should be simple to come up with a simple way to determine protocol
version.

> We could use 2 chunks of shared memory.  gpsd writes to both, ntpd
> uses a mode bit or tries both.

That could work.  Or what about the pipe protocol that gpsd uses with
chronyd?

> Back to the original problem:
> 
> address@hidden said:
> > We're looking to improve NTP's SHM refclock interface.
> 
> I looked carefully at this stuff several years ago and I couldn't
> convince myself that it would actually work correctly.  I forget the
> details.  I may be able to reconstruct something.  This stuff is
> tricky.  The details probably depend upon the machine architecture.

Yes, and trying to get gcc to not optimize out, and properly fence, the
SHM access is a bitch.

> A year or 2 ago, there was a proposal to do-it-clean and use pthreads 
> locking.  I think the discussion was on usenet.  That's a nice idea,
> but I don't know how to write the code for this case.  Does pthreads
> support locking when memory is shared between jobs rather than
> different threads or forks in the same job?  The problem is who does
> the initialization?  We don't know which side gets started first.
> What happens if one side crashes and restarts?  There should be a FAQ
> that covers this, if only to say "don't do it".

Threads are so controversial and non-portable I would prefer not to
touch that idea.

> I used to work with people who were wizards at this stuff.  I asked
> one of them how to do it.  His suggestion is roughly:

[...]

> X and Y need to be sized so they are atomically updatable.  The code
> also needs cache flushes in the right places.  I think a cache flush
> is a no-op on x86.  I think it needs real code on ARM and others.
> There should be a FAQ on this, but I didn't find it with a quick
> search.

Yup.  Every CPU is different.  Even CPUs in the same family vary in
how to get atomics right.  C compilers, if they give any support at all, 
use hackish ways to get it right.

So, any reason NOT to go to named pipes like chronyd?

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

signature.asc
Description: PGP signature