uint32_t arm-none-eabi-gcc atomic?

[Entwickler (Gast)]

Hallo,

ist Schreibzugriff aus IRQ und normalem Code aus auf uint32_t durch
__disable_irq und __enable_irq zu schützen oder nicht?

Grüsse
Entwickler

[M. Н. (Gast)]

Das hängt weniger vom Compile als vom konkreten System ab. Ich nehme mal 
an du hast einen Cortex-M irgendwas mit 32 bit Kern. Hier ist der 
Zugriff auf uint32_t und kleiner atomar*.

* Solange das 32 bit Wort auch an einer 32 bit aligned Adresse liegt. 
Das sollte bei automatischer Platzierung durch den Linker gegeben sein. 
Wenn das 32 bit Wort nicht aligned ist, dann kann bspw. ein Cortex M0 
gar nicht darauf zugreifen -> HardFault und ein Cortex M4 bspw. wird den 
Zugriff in zwei Zugriffe spalten, die dann nicht atomar sind.

[Entwickler (Gast)]

Ja, das System ist Cortex-M4 und die Variable wird vom Compiler
im RAM alloziert. Kein cast von (uint8_t*) nach (uint32_t*) oder 
ähnliches.

Danke

[Norbert (Gast)]

Entwickler schrieb:
> ist Schreibzugriff aus IRQ und normalem Code aus auf uint32_t durch
> __disable_irq und __enable_irq zu schützen oder nicht?

Nicht wenn du zB. auch DMA benutzt.

[Bauform B. (bauformb)]

Read-Modify-Write ist auch nicht atomar, z.B.

count++;
flags |= FOO;

selbst wenn es einen Maschinenbefehl INC gäbe, wäre der beim M4 nicht 
atomar.

[W.S. (Gast)]

Entwickler schrieb:
> ist Schreibzugriff aus IRQ und normalem Code aus auf uint32_t durch
> __disable_irq und __enable_irq zu schützen oder nicht?

Kannst du vielleicht auch mal nicht mit der Keule programmieren?

Bei jeder Gelegenheit mit dis/enable der Interrupts herumzufuchteln 
scheint mir eine tiefsitzende Unsitte von Leuten zu sein, die vom AVR 
herkommen. Nein, die Interrupts sollte man in Ruhe lassen und sich 
Methoden angewöhnen, die ohne solche Keulen auskommen.

Insofern kann man deine Frage mit JA oder NEIN beantworten, je nachdem 
wie du dich beim Programmieren anstellen willst. Aber das ist deine 
Obliegenheit.

W.S.

[Rolf M. (rmagnus)]

W.S. schrieb:
> Entwickler schrieb:
>> ist Schreibzugriff aus IRQ und normalem Code aus auf uint32_t durch
>> __disable_irq und __enable_irq zu schützen oder nicht?
>
> Kannst du vielleicht auch mal nicht mit der Keule programmieren?

Was ist dein Problem? Er fragt doch extra nach, ob er das braucht oder 
nicht.

[M. Н. (Gast)]

Bauform B. schrieb:
> Read-Modify-Write ist auch nicht atomar, z.B.count++;
> flags |= FOO;
> selbst wenn es einen Maschinenbefehl INC gäbe, wäre der beim M4 nicht
> atomar.

In diesem Fall kann mittels der exklusiven load und store Befehle der 
RMW Vorgang "atomar gekapselt werden". Das erfordert aber etwas 
Assembler.

[Bauform B. (bauformb)]

M. H. schrieb:
> Bauform B. schrieb:
>> Read-Modify-Write ist auch nicht atomar, z.B.count++;
>
> In diesem Fall kann mittels der exklusiven load und store Befehle der
> RMW Vorgang "atomar gekapselt werden". Das erfordert aber etwas
> Assembler.

Hat schon mal jemand gewagt, das zu verwenden? Wie war das, das R in 
RISC steht für Ridiculous, oder? Es heißt ja nicht, dass es weniger zu 
lernen gibt.

[Malte _. (malte)]

Faktisch ist ein uint32_t, wenn er denn aligned, ist, auf einem 32bitter 
wie ein Cortex-M bis auf weiteres mit gcc atomar.

Das ist aber wie ich gelernt habe nicht garantiert. Und zumindest beim 
Clang hab ich da sehr interessante Optimierungen beobachtet (die 
ungewöhnlich, aber nicht dem Standard widersprechen).
In etwa ging der Code so:

typedef struct {
 uint32_t a;
 uint8_t b;
} myType_t;

void foo(myType_t * x, myType_t * y) {
  y->a = x->a;
  y->b = x->b;
}

Der Zugriff auf a erfolgte nicht atomar. Stattdessen hat der clang 
selbstständig die Erlaubnis für nicht alignte Zugriffe angenommen und
einen 4 Byte Zugriff gemacht der 3 Byte von a und dann das 1 Byte von b 
beinhaltet hat. Dann einen 1 Byte Zugriff um das fehlende Byte von a zu 
kopieren.

[Irgend W. (Firma: egal) (irgendwer)]

M. H. schrieb:
> ..."atomar gekapselt werden".
> Das erfordert aber etwas Assembler.

Diese Arbeit kann man heutzutage durchaus dem Compiler überlassen:
- https://en.cppreference.com/w/cpp/atomic/atomic

[Wilhelm M. (wimalopaan)]

Das wird regelmäßig hier gefragt (oft auch in Zusammenhang mit 
volatile):

Beitrag "Re: c volatile -> wann bracht mans wirklich?"

[M. Н. (Gast)]

Bauform B. schrieb:
> Hat schon mal jemand gewagt, das zu verwenden?

Was heißt "gewagt"? Die Funktionalität ist weder besonders schwierig zu 
verstehen noch außergewöhnlich.

Hier ist schon in der Frage ein funktionales Beispiel:
Beitrag "STM32: LDREX/STREX vs Interruptsperre"

[Niklas G. (erlkoenig)]

Bauform B. schrieb:
> Hat schon mal jemand gewagt, das zu verwenden

Das geht sogar ganz einfach, wenn du die Atomic-Library verwendest:

https://en.cppreference.com/w/c/language/atomic
https://en.cppreference.com/w/cpp/atomic/atomic

Wenn ich mich recht erinnere, muss man noch bei 
Kontextwechseln/Interrupt-Eintritt noch ein CLREX ausführen.

Wenn du ein RTOS verwendest, basieren die Synchronisations-Primitive 
wahrscheinlich auch auf Atomics oder direkt auf den jeweiligen 
Assembler-Befehlen.

[W.S. (Gast)]

Rolf M. schrieb:
> Was ist dein Problem? Er fragt doch extra nach, ob er das braucht oder
> nicht.

ICH brauche sowas nicht. Und ich habe auch kein Problem damit. Aber ob 
der TO bei seiner Programmierweise sowas braucht, kann eigentlich nur er 
selber sagen. Allenfalls kann er seine Programmierweise ändern - sofern 
er das will. Das ist der entscheidende Punkt.

W.S.

[M. Н. (Gast)]

Niklas G. schrieb:
> Kontextwechseln/Interrupt-Eintritt noch ein CLREX ausführen.

Bei exceptions / Interrupts übernimmt das der Cortex von sich.