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

Terje Mathisen terje at tmsw.no
Sat Mar 26 22:22:23 UTC 2011

tz wrote:
> On Sat, Mar 26, 2011 at 5:26 PM, Terje Mathisen<terje at tmsw.no>  wrote:
>> 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.
> I think you will get more updates from GPSD with a faster GPS (or is
> it throttled to PPS even if not hardware PPS?).
> If the update can tolerate 2 seconds sleep, what is wrong with simply
> waiting 1 system tick (10mS typical and likely to have barriers
> executed in the tick routine) between two comparison (memcpy) reads of
> a single SHM buffer so the cache would update from any writes through
> to the buffer?  usleep(10000) is a lot less code and overhead than any
> of these other complex mechanisms.

That would indeed work, but it is an OS call, it could just as well be a 
semaphore call.

My 4-wide buffer is neither  complex nor a lot of overhead:

The total cost is specifically a total of 2 or 3 clock cycles, to mask 
the counter value and to generate the desired buffer offset which 
requires a mul-by-24 which is handled with a shift&add on many 
architectures, and a single LEA to multiply by 3 on x86, whereupon the 
individual members can be loaded with a scaled-by-8 indexing operation.

What you save is the need to reread/compare/sleep/whatever to handle the 
case where you try to read at the same time as gpsd is writing: This is 
far more costly!


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

More information about the hackers mailing list