[ntp:hackers] ntpd shm changes

Harlan Stenn stenn at ntp.org
Sat Mar 19 01:38:40 UTC 2011

Dave Hart wrote:

> Assuming all the shared memory struct variables are declared volatile,
> preventing the compiler from reordering accesses, I think we can
> dispense with the odd/even concept as well, and simply rely on count's
> update being atomic.  That does imply we need to allocate 64 bits for
> count, so that access _is_ atomic on 64-bit, while using only the low
> order 32 bits from 32-bit code.

I have not dug in to the required behavior of compilers in a while.

I learned (and it might be wrong or incomplete) that volatile meant that
if you were *reading* a value you could not depend on the value being
the same as it was on a previous/earlier read.  I do not recall any
statements about reordering accesses, though.  But there could well be,
as I would expect that the semantics of 'volatile' became more refined
from what they were in the late 80s.

HÃ¥kan Johansson <f96hajo at chalmers.se wrote:
>> Also nice would be if the consumer (ntpd) would write some
>> information of its current status (stratum, active source, ... -
>> basically what is in a NTP network packet) to also allow the
>> interface to be used for alternative transmission methods, such as
>> PPS-like over a serial line.

Have you seen ntp_gettime(2)?  It may be closer to what you are looking
for than gettime().


More information about the hackers mailing list