Avoiding race in a sub-millisecond TOD timer Part of the project I am working on is to maintain the time-of-day, at the sub-millisecond accuracy, while not overwhelming CPU.
The controller has a pretty standard timer, with two registers, COUNTER and PRELOAD. On each system tick COUNTER is decremented; once it reaches 0, the timer posts an interrupt, and reloads COUNTER with the value from PRELOAD.
The value in PRELOAD is calculated off-line, to let the counter expire (and post the interrupt), say, every 100 milliseconds. COUNTER is readable at any time, which allows for a sum-millisecond precision. Yet another timer register, STATUS, has a TIMER_STATUS_IF bit, which determines the state of the timer interrupt.
The timer's registers are memory mapped. Their definitions (along with the definition of timer) come from the manufacturer's #include file. The actual address map is irrelevant.
Here is the code:
static volatile uint32_t ticks;

void ISR timer_isr() {
    ticks++;
    timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF;
}

uint64_t usecs() {
    uint32_t counter1 = timer-&gt;COUNTER;
    uint32_t ticks1 = ticks;
    uint32_t counter2 = timer-&gt;COUNTER;
    uint32_t ticks2 = ticks;

    if (timer-&gt;STATUS &amp; TIMER_STATUS_IF) {
        // The interrupt has been asserted, and the counter has been reloaded,
        // but the ISR has not been run (we are called from the higher priority
        // ISR). Increment ticks manually.
        assert(ticks1 == ticks2);
        ticks2 += 1;
    } else if (counter1 &gt; counter2) {
        // We know that between reading counters the reload did not happen.
        // Trust the first reading of ticks.
        ticks2 = ticks1;
    }
    else { // Nothing happens here. It is purely an explanation.
        // We know that between reading counters the reload did happen.
        // Trust the second reading of ticks.
    }

    return ticks2 * US_PER_TICK + (timer-&gt;PRELOAD - counter2) / CLOCKS_PER_USEC;
}

This works fine unless some high priority ISR takes more than 100 ms to complete. I am fine with it. If any ISR takes that long, it is much more serious design problem.
What I don't like here.
I am a strong advocate of a comment-less style. To quote myself, &quot;an explanatory comment means that you fail to express the intention in the code&quot;. However, I feel I need a large explanatory comment. Any hint on how to remove it is much appreciated.
TL;DR
For a bit of context, the code I inherited (not for a review)

uint64_t usecs() {
    uint32_t counter = timer-&gt;COUNTER;
    uint32_t ticks = ticks;
    return ticks * US_PER_TICK + (timer-&gt;PRELOAD - counter) / CLOCKS_PER_USEC;
}


once in a while exhibited time travel for about 100 ms into the future.
Carefully examine all possible interactions between interrupts
There are many possible ways interrupts can happen, you should take some time and carefully try to map them out. I think you missed a few corner cases in case where usecs() is called from a higher priority context than timer_isr(). First, given your description, the function usecs() can be called either from a low or a high priority context:
Low priority call to usecs()
It's either not called from an interrupt context, or from an interrupt with a lower priority than the timer overflow interrupt. In this context, usecs() might be interrupted by timer_isr() at any point during its execution. So look at all the possible places where the timer_isr() could fire:
// 1
uint32_t counter1 = timer-&gt;COUNTER;
// 2
uint32_t ticks1 = ticks;
// 3
uint32_t counter2 = timer-&gt;COUNTER;
// 4
uint32_t ticks2 = ticks;
// 5

Before I am going to look at all 5 possibilities, I'm also going to make some assumptions:

Any higher interrupts together will never take more than 100 milliseconds. This should be reasonable, and avoids us having to worry about the timer overflowing twice while usecs() runs.
The COUNTER effectively gets reset to PRELOAD by the hardware during the interrupt to timer_isr(). You must verify this by reading the documentation of the MCU.

So now for the five possibilities of where the timer reset happens, and after the four statements have run the results will be:

ticks1 == ticks2 and counter1 &gt; counter2 (trivial case)
ticks1 == ticks2 and counter1 &lt; counter2 (only counter2 is valid)
ticks1 != ticks2 and counter1 &lt; counter2 (either ticks1+counter1 or ticks2+counter2 are valid)
ticks1 != ticks2 and counter1 &gt; counter2 (only ticks1 is valid)
ticks1 == ticks2 and counter1 &gt; counter2 (trivial case)

It looks like your code handles all these cases correctly.
High priority calls to usecs()
Here we can never be that timer_isr() interrupts usecs(), but it could be that usecs() interrupted timer_isr(). Let's look at those cases separately.
usecs() did not interrupt timer_isr()
The question is now, what happens when the timer resets? Again, check the documentation of your MCU, but I am assuming that COUNTER will be reset to PRELOAD, just that timer_isr() doesn't fire because we are already in a higher level interrupt. So now ticks1 == ticks2 will always be true. We still have the five positions where the reset can happen:

counter1 &gt; counter2 (ticks1 and ticks2 are behind)
counter1 &lt; counter2 (ticks2 is behind)
counter1 &lt; counter2 (ticks2 is behind)
counter1 &gt; counter2 (everything is valid)
counter1 &gt; counter2 (everything is valid)

Oops, you cannot distinguish case 1 from cases 4 and 5 just by looking at the counter values. The TIMER_STATUS_IF flag also doesn't help in distinguishing what happened, at least not if you check it after reading the counters. So you have to read the counter again:
if (timer-&gt;STATUS &amp; TIMER_STATUS_IF) {
    // The counters wrapped somewhere prior to exactly this if-statement.
    // We assume it won't wrap again from here, because all interrupts will
    // be handled in less than 100 ms.
    counter2 = timer-&gt;COUNTER;
    ticks2 += 1;
} ...

usecs() did interrupt timer_isr()
In a way this looks simpler, because we know the counter reset just before usecs() was called, so we don't have to worry about the counters being able to reset during usecs(). However, now we have to worry about where exactly in timer_isr() we had the higher level interrupt. Again there are several possibilities:
// 1
ticks++;
// 2
timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF;
// 3

Oops, there is no way to distinguish case 1 from case 2 from usecs()! Reordering statements won't help here, there will always be a point right before and one right after the increment. The only way I see is to ensure both ticks++ and timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF are executed atomically. Perhaps this can be done by having timer_isr() disable higher level interrupts:
cli(); // disable all interrupts
ticks++;
timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF;
sei(); // reenable interrupts

This should make usecs() work correctly.