[Top][All Lists]

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

Re: [gpsd-dev] SHM refclock improvements

From: Gary E. Miller
Subject: Re: [gpsd-dev] SHM refclock improvements
Date: Tue, 28 Aug 2012 15:51:58 -0700

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

> 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

> 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?

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

Attachment: signature.asc
Description: PGP signature

reply via email to

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