[ntp:hackers] ntpd shm changes
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