[ntp:hackers] [Gpsd-dev] ntpd shm changes
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 .
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 . Lacking
> compiler support for memory barriers, the arguably redundant use of
> valid and count-checking might keep us out of trouble with reordering
> 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