[time-nuts] FreeBSD, NetBSD, or Minix-III?

[M. Warner Losh]

In message: <20090517233218.01D11BCE6 at ip-64-139-1-69.sjc.megapath.net>
            Hal Murray <hmurray at megapathdsl.net> writes:
: 
: > If a carry occurs between the two high readings, then we can expect
: > the  low reading to be close to 0 on either side of the wrapping.
: > Which side determines which holds the right value. If the wrapping of
: > counter happend before reading the low part, then the low part will
: > be just above 0 where as if it happends just after the low read but
: > before the high read, the low read will be just below the maximum
: > counter value. 
: 
: I'm interested in the case where interrupts and scheduling are enabled so 
: there may be arbitrary gaps inserted into the simple code.

Interrupts enabled means that you can't make it reliable.

: I think this case doesn't work right:
:   read high
:   overflow
:   long gap
:   read low
:   read high
: 
: Suppose the low half overflows once a second so I can use handy numbers.
: 
: If the long gap is 0.6 second, the MSB of the low half will be on so we use 
: the first high sample.  That corresponds to a time 0.4 seconds before the 
: overflow.  That's outside the first-last window.  (I'm assuming all the reads 
: and checking take negligible time which seems reasonable if we are talking 
: about 0.6 seconds of gap.)
: 
: I think there is a mirror image case:
:   read high
:   read low
:   long gap
:   overflow
:   read high
: 
: Suppose the long gap is 0,6 seconds so the low half will read 0.4.  The MSB 
: will be off so we use the second high sample.  That will produce an answer 
: 0.4 seconds into the future.

Yes, this is why you must disable interrupts.  You aren't racing other
parts of software, but rather you are racing the wrapping of the
counter in hardware.  To reliably cope, you have to make sure that a
third-party can't interrupt you producing the cases you describe...

Warner