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

Dave Hart davehart at gmail.com
Sat Mar 19 05:24:49 UTC 2011


On Sat, Mar 19, 2011 at 03:38 UTC, tz <thomas at mich.com> wrote:
> 2011/3/18 Dave Hart <hart at ntp.org>:
>> I am not suggesting changing the interpretation or protocol of mode 0
>> or mode 1, but in an imaginary mode 2 with volatile keywords on all
>> the shm members, I think we can safely share the memory relying only
>> on 32-bit operations on count being atomic.
>
> Does this fix the problem on a multicore machine?
>
> NTPD - reads valid as 1
>           sets valid to 0 - GPSD
> NTPD - reads count once.
>           some other work - GPSD
> NTPD - reads count again, (are equal)
>           increment count - GPSD
> NTPD - housekeeping
>           begins update writing - GPSD
> NTPD - reads half-changed values.
> ...

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].

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.

If this discussion is not a good fit for gpsd-dev@ we can conduct it
on hackers at lists.ntp.org if interested gpsd folks would subscribe, or
Harlan has offered to host a shm-specific list at lists.ntp.org if
people would prefer that.

Cheers,
Dave Hart

[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Volatiles.html
[2] http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Atomic-Builtins.html


More information about the hackers mailing list