[ntp:hackers] [Gpsd-dev] ntpd shm changes

Terje Mathisen terje at tmsw.no
Sat Mar 19 11:20:13 UTC 2011

Dave Hart wrote:
> That's not the current protocol and I don't think it's been proposed,
> and you show why it doesn't work.  The two reads of count are before
> and after reading the timestamps, not both before.
> To answer Harlan's query, yes, volatile restricts the compiler from
> reordering accesses (reads and writes) amongst volatile variables,
> which is why I suggest every member of the structs (or the struct
> types) be volatile.  See for example [1].

I have spent a few years in comp.arch where the issue of 'volatile' 
comes up regularly:

It _does not_ do what you believe it to do!

In particular, you cannot _depend_ on volatile as a portable method to 
handle cross-cpu synchronization. :-(

It is still the best option available if you have to avoid proper, 
os/cpu-specific, atomic operations.

> To play it extra safe, we could retain valid (though I'd argue for
> only the producer modifying it) and use a memory-barrier-producing
> construct where available, such as __sync_syncrohronize [2].  Lacking
> compiler support for memory barriers, the arguably redundant use of
> valid and count-checking might keep us out of trouble with reordering
> processors.
> I've not heard of problems with the newer protocol (mode 1 in shared
> memory struct) despite it lacking volatile qualifiers and memory
> barriers.  Adding volatile (and where available a full memory barrier)
> certainly shouldn't make things worse.

The best you can do with a single producer and one/multiple readers 
(which are allowed to read the same data), is probably to have multiple 
slots for the data packets together with a single pointer to the 
current/last updated slot.

The pointer can even be a simple index, using a byte variable makes it 
impossible for a reader to read a partially updated value.


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

More information about the hackers mailing list