order of volatile access undefined

Warnung Gast #2609115
Lesenswert?
• ▲
▼ 
Hi, ich bekommen von meinem Compiler dauernd folgende Warnung:

>Warning[Pa082]: undefined behavior: the order of volatile accesses is >undefined 
in this statement

Das Programm besteht sinngemäß aus folgendem:

volatile uint16_t Var_1;
volatile uint16_t Var_2;
  .
  .
  .
Var_1 = (Var_1 + Var_2)/2;



Wenn ich zusätzliche Zeilen einfüge und lokale Kopien von den Variablen 
verwende, dann gibt es die Warnung nicht mehr, ...aber ich sehe an 
dieser Stelle beim besten Willen kein Problem an der 
Verarbeitungsreihenfolge, oder gelten für volatile andere Gesetze?


Warum also gibt mir der Compiler dennoch solche (sinnfreien?) Warnungen 
aus?


mfg
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Krapao Gast #2609138
Lesenswert?
• ▲
▼ 
Die Warnung ist nicht sinnfrei. Du musst überlegen, ob dein Projekt das 
angewarnte Problem betreffen kann. Bei volatile Variablen kann es sehr 
wohl eine Rolle spielen, welche der Variablen in einem Ausdruck zuerst 
abgefragt wird.

Wenn du lokale Kopien verwenden kannst, legst du dadurch die Reihenfolge 
der Zugriffe fest. Eine andere Methode wäre, die Zugriffe auf Var_1 und 
Var_2 atomar zu machen, also z.B. Interrupts zu sperren, die Var_1 und 
Var_2 ändern. A propos atomar - ist ein uint16_t Zugriff auf deinem 
Target atomar?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Warnung Gast #2609182
Lesenswert?
• ▲
▼ 
aah, ok, danke.

gibt es noch weitere Fälle außer einem möglichen Interrupt, der auf das 
Ergebnis Einfluss ausüben könnte?


auf was möchtest du mit der Frage hinweisen, ob die uint16_t atomar 
sind?

welche Konsequenzen bringt diese Eigenschaft für meinen Programmablauf 
mit sich?

mfg
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Krapao Gast #2609345
Lesenswert?
• ▲
▼ 
> auf was möchtest du mit der Frage hinweisen, ob die uint16_t atomar
> sind?

Ob du dir schon Gedanken dazu gemacht hast, als du die Zeile oben so 
schrieben hast.

Bei einem 8-Bit AVR, den ich von den µCs am häufigsten programmiere, 
sind uint16_t Zugriffe nicht atomar und bei den daraus möglichen Bugs 
kann man sich tot suchen z. B. wenn entweder das MSB oder das LSB eines 
uint16_t Werts zwischen "dem Lesezugriff" (= mehrere Zugriffe auf 
ASM-Ebene) aktualisiert wurde. In deinem Fall betrifft das sogar zwei 
Variablen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Uli Gast #2609380
Lesenswert?
• ▲
▼ 
Eigentlich muesste es genügen, die Variablen direkt im Statement nach 
uint16 zu casten, um die Warnungen loszuwerden. (zumindestr eine davon)
etwa in der Art

> Var_1 = (((uint16_t)Var_1) + Var_2)/2;

Und ansonsten wäre ich auch echt vorsichiig mit der Annahme "sinnfrei", 
speziell im Umfeld "volatile".

beste Grüße
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren