Race-Condition "reparieren"?

Hallo Forenuser,

mir ist heute beim Programmieren eines STM32F411 Controllers durch ein 
zunaechst nicht funktionierendes Programm eine Sache aufgefallen, die 
ich gerne mit Euch diskutieren würde:

Ich will eine Funktion programmieren, die ganz so wie im Arduino-Code 
einen Wert für die abgelaufenen Mikrosekunden nach dem Programmstart 
(bzw. Timer-Start) liefert.
Also eben: uint32_t micros(void) sollte eigentlich problemlos sein, aber 
- wir werden sehen.

Ich habe mir einen Timer gesetzt, der alle 100ms einen 
Overflow-Interrupt erzeugt. Dann erhoehe ich einen globalen Zaehler 
glb_Millis um 100, und kehre sofort zurueck. Diese Variable ist per 
"volatile" geschützt. glb_Millis += 100; ist zwar nicht atomar, aber ich 
schreibe ja nur in der Interrupt-Routine in die Variable.
void TIM5_IRQHandler(void)
{
   glb_Millis += 100;
   // Interrupt-Flag löschen usw. habe ich hier weggelassen.
}


Die Funktion muss dann nur noch den Wert der Mikrosekunden als micros = 
Millisekunden * 1000 + Offset berechnen. Millisekunden * 1000, weil ja 
eine Millisekunde 1000 Mikrosekunden hat. Den Offset muss man aus dem 
aktuellen Zaehlerstand TIM5->CNT des Timers bestimmen, der bei mir von 0 
bis 999.999 hoch zaehlt. Der Timer 5 ist ein 32-Bit Timer, das sollte 
also funktionieren. Die Taktfrequenz ist 100 Mhz.
Offset  = TIM5->CNT / 10; und zusammen:

uint32_t micros(void)
{
__disable_irq();

uint32_t mic = glb_Millis * 1000 + TIM5->CNT / 10;

__enable_irq();
return (mic);


Die Funktion funktioniert im Prinzip - aber irgendwann mal alle heiligen 
Zeiten nicht. Natürlich gerade dann, wenn der Timer zwischendurch 
übergelaufen ist. Logischerweise sollte eine Zeitmessung immer 
aufsteigende Wert liefern, das tut sie aber nur in 99.999% aller Fälle.
Und nur, wenn man sie zweimal in ganz ganz kurzen Abständen aufruft.

Beispiel:
1. Aufruf:
glb_Millis = 5000; TIM5->CNT = 999990;
Der Timer ist also kurz vor dem Überlauf.
Funktionsergebnis: mic = 5000 * 1000 + 999990 / 10 = 5099999 us.

2. Aufruf (unmittelbar nachher)
glb_Millis = 5000; (!!!!) TIM5->CNT = 3;

Der Timer ist übergelaufen, und wurde wieder von 0 auf aufwärts zählend 
gestartet. Aber glb_Millis ist noch immer 5000, anstatt 5100, d.h. die 
Interrupt-Routine ist noch nicht aufgerufen worden!
Nun geht die Berechnung natürlich schief:
Funktionsergebnis: mic = 5000 * 1000 + 3 / 10 = 5000000 us.
Richtig wäre natürlich 5100 * 1000 + 3 / 10 = 5100000 us.

Natürlich kommt das sehr selten vor, aber so alle 1-2 min ist es mal 
soweit. Mein Fix bisher: Alten Funktionswert mic abspeichern, in 
prev_mic. Und sollte mal mic < prev_mic sein, dann mic += 100000; um die 
Overflow-Bedingung zu erkennen. Das läuft, aber es kann mich nicht ganz 
zufrieden stellen! Der Post-Race Fix? Es sollte doch gar nicht erst dazu 
kommen!

Es kann nie schaden nach zu sehen, wie es denn andere machen. So lag es 
nahe, im Original-Arduino Code zu schauen. Dort steht (überflüssiges 
entfernt):

#ifdef TIFR0
  if ((TIFR0 & _BV(TOV0)) && (t < 255))
    m++;
#else
  if ((TIFR & _BV(TOV0)) && (t < 255))
    m++;
#endif

Oh! Die #ifdef behandeln nur zwei unterschiedliche Namen des Timers, 
aber der Fix ist derselbe: Wenn _BV(TOV0), also Overflow stattgefunden 
hat, und der Zähler < 255 ist (Overflow also nicht lange her sein 
kann...) dann erhoehe m einfach um 1. Später kommt dann:
return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
Also im Prinzip derselbe Fix, nur mit anderen Werten.

Tja, und nun natürlich die entscheidende Frage:
Ist es wirklich unmöglich, jederzeit korrekte Werte von glb_Millis und 
TIM5->CNT zu lesen (das ist ja das Problem, die Werte passen im 
Fehlerfalle nicht zusammen) oder waren die Arduino Programmierer ebenso 
blind oder unwissend wie ich?

Viele Grüße
Thomas