[ntp:hackers] [Gpsd-dev] Single-writer/many-reader consistency

Terje Mathisen terje at tmsw.no
Sat Mar 26 21:26:18 UTC 2011

Dave Hart wrote:
> On Sat, Mar 26, 2011 at 14:58 UTC, Terje Mathisen<terje at tmsw.no>  wrote:
>> I suggest we extend the buffer size to 4 entries, making the entire block
>> 120 bytes, since this will fit inside the same two 64-byte cache lines as
>> the current layout needs.
> For refclock_shm's shared memory, I am increasingly fond of Terje's
> array of four timestamps and lock-free sequence number/index.  In that


> context it seems to me even without memory barriers being emitted on
> an architecture where they are in theory needed, ring buffering will
> make it practically impossible to get an inconsistent set of
> timestamps.

This is exactly what I'm trying to do: Even very simple reader code will 
work at better than 5 nines reliability, i.e. even without a read 
barrier or the check so see if the counter has been updated.

The next level is to discard any sample read in during a counter update 
by the writer, and retry.

This is effectively _never_ needed though, since my suggested code for a 
4-entry buffer just has to make sure that the counter has been updated 
by less than 3 samples, i.e. making sure that maximum 2 seconds have 
passed with the process sleeping in the middle of the read operation. 
Since the ntpd process is as (near-) realtime priority as we can make 
it, sleeping for two+ seconds like that means that something is _very_ 
wrong indeed, but the shm code would simply retry the read and succeed.

>> The final 8 bytes (to make the total 128) is where I want to locate an
>> endian-detecting marker: "GPSD-NTP":
> Are you thinking of an architecture that allows for per-procecess
> endian selection, or what purpose do you have in mind?  Call it a
> magic number and I like the idea of sanity checking we're looking at
> what we think we're looking at...

All of those:

1) It is indeed a magic number, until the reader process finds that 
value nothing can be read in.

2) It is also an endian detector _if_ you are on one of the few 
architectures which allow a program to be compiled for either the 
default or the opposite endianness. For this very particular case you 
could even include code to swap the byte order of all the data items, 
but I would rather log an error message and skip the shm driver activation.

3) It overlays the current mode value, and none of the 8 bytes contain 
either 1 or 0 which are the only legal values for the current interface, 
i.e. a current-generation ntpd shm driver will never pick up any bogus 
timestamps from a new-model gpsd.
> Cheers,
> Dave Hart

- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

More information about the hackers mailing list