Re: [gpsd-dev] SHM refclock improvements

[Harlan Stenn]

"Gary E. Miller" writes:
> On Tue, 28 Aug 2012 15:01:51 -0700
> Hal Murray <address@hidden> wrote:
> > address@hidden said:
> > > We're looking to improve NTP's SHM refclock interface.
> >=20
> > 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.

I don't know if 'volatile' will help there or not.

I used to do a *lot* of work with SYSVIPC, including SHM, SEM, and the
message queue stuff.  Yeah, it's miserable and it doesn't get any easier
as compilers "go deeper" or as stages along the way sometimes aren't
done right.

> > A year or 2 ago, there was a proposal to do-it-clean and use pthreads=20
> > 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'm in that same camp too, and I'm hearing from folks I trust that
things are much better now.

It wasn't all that long ago that NTP dropped support for K&R C.  We
still haven't officially said if we require C89 or C99, but since I
believe some C99 stuff has snuck in and nobody has complained...

This also gets a lot easier now that "let's use this ancient hardware"
now means an x86 box that can run a number of current free OSes, as
opposed to some much older hardware that runs a proprietary OS and it is
a PITA to get a newer C compiler on it.

> > 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,=20
> use hackish ways to get it right.
> 
> So, any reason NOT to go to named pipes like chronyd?

NTP would need non-GPL'd code, and if this was to happen for 4.2.8 it
would need to be non-blocking.  It would also have to happen very soon.

H