MCU-Programmierung - C++ O2-Optimierung unterbricht While-Schleife

( Site-übergreifendes Duplikat auf SO über den Thread-Fall und nicht über den Interrupt/Signal-Handler-Fall). Auch verwandt: Wann sollte man volatile mit Multi-Threading verwenden?

Ein Datenrennen auf einer Nicht- atomicVariablen ¹ ist Undefined Behavior in C++11 ² . dh potentiell gleichzeitiges Lesen+Schreiben oder Schreiben+Schreiben ohne irgendeine Synchronisation, um eine Ereignis-bevor-Beziehung bereitzustellen, z. B. eine Mutex- oder Release/Acquire-Synchronisation.

Der Compiler darf davon ausgehen, dass sich choicezwischen zwei Lesevorgängen kein anderer Thread geändert hat (denn das wäre Data-Race UB ( Undefined Behavior )), sodass er CSE durchführen und den Check aus der Schleife ziehen kann.

Dies ist in der Tat das, was gcc tut (und die meisten anderen Compiler auch):

while(!choice){}

optimiert in asm, das so aussieht:

if(!choice)     // conditional branch outside the loop to skip it
    while(1){}  // infinite loop, like ARM  .L2: b .L2

Dies geschieht im zielunabhängigen Teil von gcc, gilt also für alle Architekturen.

Sie möchten , dass der Compiler diese Art der Optimierung durchführen kann, da echter Code Dinge wie for (int i=0 ; i < global_size ; i++ ) { ... }. Sie möchten, dass der Compiler in der Lage ist, das Global außerhalb der Schleife zu laden, und es nicht bei jedem Schleifendurchlauf oder für jeden späteren Zugriff in einer Funktion neu zu laden. Daten müssen sich in Registern befinden, damit die CPU damit arbeiten kann, nicht im Speicher.

Der Compiler könnte sogar davon ausgehen, dass der Code nie mit erreicht choice == 0wird, da eine Endlosschleife ohne Nebenwirkungen Undefined Behaviour ist. (Lesen / Schreiben von Nicht volatile-Variablen zählen nicht als Nebenwirkungen). Sachen wie printfsind ein Nebeneffekt, aber das Aufrufen einer Nicht-Inline-Funktion würde den Compiler auch daran hindern, das erneute Lesen von choicewegzuoptimieren, es sei denn, es wäre static int choice. (Dann würde der Compiler wissen, dass es nicht geändert werden printfkann, es sei denn, etwas in dieser Kompilierungseinheit wird &choicean eine Nicht-Inline-Funktion übergeben. Das heißt , die Escape-Analyse könnte es dem Compiler ermöglichen zu beweisen , dass static int choicees nicht durch einen Aufruf an eine "unbekannte" geändert werden kann Nicht-Inline-Funktion.)

In der Praxis optimieren echte Compiler einfache Endlosschleifen nicht weg, sie gehen davon aus (als Qualitätsproblem der Implementierung oder so), dass Sie schreiben wollten while(42){}. Aber ein Beispiel in https://en.cppreference.com/w/cpp/language/ub zeigt, dass Clang eine Endlosschleife wegoptimiert, wenn es Code ohne Nebeneffekte gab, den es wegoptimierte.

Offiziell unterstützte 100% portierbare / legale C++11-Möglichkeiten, dies zu tun:

Sie haben nicht wirklich mehrere Threads, Sie haben einen Interrupt-Handler. In C++11-Begriffen ist das genau wie ein Signalhandler: Er kann asynchron mit Ihrem Hauptprogramm laufen, aber auf demselben Kern.

C und C++ haben dafür schon lange eine Lösung: volatile sig_atomic_tEs ist garantiert in Ordnung, in einen Signalhandler zu schreiben und in Ihrem Hauptprogramm zu lesen

Ein ganzzahliger Typ, auf den als atomare Entität zugegriffen werden kann, selbst wenn asynchrone Interrupts durch Signale vorhanden sind.

void reader() {

    volatile sig_atomic_t shared_choice;
    auto handler = a lambda that sets shared_choice;

    ... register lambda as interrupt handler

    sig_atomic_t choice;        // non-volatile local to read it into
    while((choice=shared_choice) == 0){
        // if your CPU has any kind of power-saving instruction like x86 pause, do it here.
        // or a sleep-until-next-interrupt like x86 hlt
    }

    ... unregister it.

    switch(choice) {
        case 1: goto constant;
        ...
        case 0: // you could build the loop around this switch instead of a separate spinloop
                // but it doesn't matter much
    }
}

Andere Typen werden vom Standard nicht als atomar garantiert (obwohl sie in der Praxis auf normalen Architekturen wie x86volatile und ARM mindestens bis zu einer Zeigerbreite reichen , da Locals natürlich ausgerichtet werden. ist ein einzelnes Byte, und moderne ISAs können a atomar speichern Byte ohne Lesen/Ändern/Schreiben des umgebenden Wortes, trotz aller Fehlinformationen, die Sie vielleicht über wortorientierte CPUs gehört haben ).uint8_t

Was Sie wirklich möchten, ist eine Möglichkeit, einen bestimmten Zugriff flüchtig zu machen, anstatt eine separate Variable zu benötigen. Sie können das vielleicht mit tun *(volatile sig_atomic_t*)&choice, wie das ACCESS_ONCEMakro des Linux-Kernels, aber Linux wird mit deaktiviertem Strict-Aliasing kompiliert, um so etwas sicher zu machen. Ich denke, in der Praxis würde das auf gcc/clang funktionieren, aber ich denke, es ist kein streng legales C++.

Mit std::atomic<T>für lock-freeT

(mit std::memory_order_relaxedum eine effiziente asm ohne Barriereanweisungen zu erhalten, wie Sie von bekommen können volatile)

C++11 führt einen Standardmechanismus ein, um den Fall zu handhaben, in dem ein Thread eine Variable liest, während ein anderer Thread (oder Signalhandler) sie schreibt.

Es bietet Kontrolle über die Speicherreihenfolge, standardmäßig mit sequentieller Konsistenz, was teuer und für Ihren Fall nicht erforderlich ist. std::memory_order_relaxedAtomic Loads/Stores werden mit dem gleichen Asm (für Ihre K60 ARM Cortex-M4-CPU) wie kompiliert volatile uint8_t, mit dem Vorteil, dass Sie a uint8_tanstelle der Breite verwenden sig_atomic_tkönnen, während Sie dennoch sogar einen Hinweis auf C++11 Data Race UB vermeiden .

( Natürlich ist es nur auf Plattformen portierbar, auf denen atomic<T>Ihr T lock-frei ist; andernfalls kann der asynchrone Zugriff vom Hauptprogramm und ein Interrupt-Handler zu einem Deadlock führen . C++-Implementierungen dürfen keine Schreibvorgänge für umgebende Objekte erfinden , also wenn uint8_tüberhaupt , es sollte lock-free atomic sein.Oder verwenden Sie einfach unsigned char.Aber für Typen, die zu breit sind, um natürlich atomar zu sein, atomic<T>wird eine versteckte Sperre verwendet.Mit normalem Code ist es nicht möglich, jemals aufzuwachen und eine Sperre freizugeben, während der einzige CPU-Kern in einem steckt Interrupt-Handler, Sie sind am Arsch, wenn ein Signal/Interrupt ankommt, während diese Sperre gehalten wird.)

#include <atomic>
#include <stdint.h>

volatile uint8_t v;
std::atomic<uint8_t> a;

void a_reader() {
    while (a.load(std::memory_order_relaxed) == 0) {}
    // std::atomic_signal_fence(std::memory_order_acquire); // optional
}
void v_reader() {
    while (v == 0) {}
}

Beide kompilieren mit gcc7.2 -O3 für ARM im Godbolt-Compiler-Explorer auf dieselbe Anweisung

a_reader():
    ldr     r2, .L7      @ load the address of the global
.L2:                     @ do {
    ldrb    r3, [r2]        @ zero_extendqisi2
    cmp     r3, #0
    beq     .L2          @ }while(choice eq 0)
    bx      lr
.L7:
    .word   .LANCHOR0


void v_writer() {
    v = 1;
}

void a_writer() {
    // a = 1;  // seq_cst needs a DMB, or x86 xchg or mfence
    a.store(1, std::memory_order_relaxed);
}

ARM asm für beide:

    ldr     r3, .L15
    movs    r2, #1
    strb    r2, [r3, #1]
    bx      lr

In diesem Fall kann also für diese Implementierung volatiledasselbe wie std::atomic. Auf einigen Plattformen kann volatiledie Verwendung spezieller Anweisungen erforderlich sein, die für den Zugriff auf speicherabgebildete E/A-Register erforderlich sind. (Mir sind keine solchen Plattformen bekannt, und bei ARM ist dies nicht der Fall. Aber das ist eine Funktion, die volatileSie definitiv nicht wollen).

Mit atomickönnen Sie sogar die Neuordnung zur Kompilierzeit in Bezug auf nicht-atomare Variablen blockieren, ohne zusätzliche Laufzeitkosten, wenn Sie vorsichtig sind.

Verwenden Sie nicht .load(mo_acquire), das macht asm sicher in Bezug auf andere Threads, die gleichzeitig auf anderen Kernen laufen. Verwenden Sie stattdessen entspannte Loads/Stores und verwenden atomic_signal_fenceSie (nicht thread_fence) nach einem entspannten Laden oder vor einem entspannten Store , um eine Bestellung zu erwerben oder freizugeben.

Ein möglicher Anwendungsfall wäre ein Interrupt-Handler, der einen kleinen Puffer schreibt und dann ein atomisches Flag setzt, um anzuzeigen, dass er bereit ist. Oder ein atomarer Index, um anzugeben, welcher einer Gruppe von Puffern.

Beachten Sie, dass Sie, wenn der Interrupt-Handler erneut ausgeführt werden kann, während der Hauptcode noch den Puffer liest, ein Data Race UB haben (und einen tatsächlichen Fehler auf echter Hardware). UB (was der Compiler annehmen sollte, passiert nie).

Aber es ist nur UB, wenn es tatsächlich zur Laufzeit passiert; Wenn Ihr eingebettetes System über Echtzeitgarantien verfügt, können Sie möglicherweise garantieren, dass der Leser immer das Flag überprüfen und die nicht atomaren Daten lesen kann, bevor der Interrupt erneut ausgelöst werden kann, selbst im schlimmsten Fall, wenn ein anderer Interrupt eingeht und verzögert Dinge. Möglicherweise benötigen Sie eine Art Speicherbarriere, um sicherzustellen, dass der Compiler nicht optimiert, indem er weiterhin auf den Puffer verweist, anstatt auf das andere Objekt, in das Sie den Puffer einlesen. Der Compiler versteht nicht, dass zur Vermeidung von UB der Puffer sofort einmal gelesen werden muss, es sei denn, Sie sagen ihm das irgendwie. (Etwas wie GNU C asm("":::"memory")sollte es tun, oder sogar asm(""::"m"(shared_buffer[0]):"memory")).

Natürlich werden Lese-/Änderungs-/Schreiboperationen wie a++anders vonv++ , zu einem Thread-sicheren atomaren RMW kompiliert , indem eine LL/SC-Wiederholungsschleife oder ein x86 verwendet wird lock add [mem], 1. Die volatileVersion wird zu einem Ladevorgang kompiliert und dann zu einem separaten Speicher. Sie können dies mit Atomen ausdrücken wie:

uint8_t non_atomic_inc() {
    auto tmp = a.load(std::memory_order_relaxed);
    uint8_t old_val = tmp;
    tmp++;
    a.store(tmp, std::memory_order_relaxed);
    return old_val;
}

choiceWenn Sie tatsächlich jemals den Speicher erhöhen möchten , sollten Sie in Betracht ziehen volatile, Syntaxschmerzen zu vermeiden, wenn Sie dies anstelle von tatsächlichen atomaren Inkrementen möchten. Denken Sie jedoch daran, dass jeder Zugriff auf ein volatileoder atomicein zusätzliches Laden oder Speichern ist. Sie sollten also wirklich nur auswählen, wann Sie es in ein nicht atomares / nicht flüchtiges Lokal einlesen möchten.

Compiler optimieren derzeit keine atomaren , aber der Standard erlaubt es in Fällen, die sicher sind, es sei denn, Sie verwenden volatile atomic<uint8_t> choice.

Nochmals , was wir wirklich mögen, ist atomicder Zugriff, während der Interrupt-Handler registriert ist, dann der normale Zugriff.

C++20 stellt dies bereitstd::atomic_ref<>

Aber weder gcc noch clang unterstützen dies tatsächlich in ihrer Standardbibliothek (libstdc++ oder libc++). no member named 'atomic_ref' in namespace 'std', mit gcc und clang-std=gnu++2a . Es sollte jedoch kein Problem sein, es tatsächlich zu implementieren; GNU-C-Builtins __atomic_loadarbeiten gerne mit regulären Objekten, daher erfolgt die Atomizität eher pro Zugriff als pro Objekt.

void reader(){ 
    uint8_t choice;
    {  // limited scope for the atomic reference
       std::atomic_ref<uint8_t> atomic_choice(choice);
       auto choice_setter = [&atomic_choice] (int x) { atomic_choice = x; };

       ui::Context::addEventListener(ui::EventType::JOYSTICK_DOWN, &choice_setter);
       while(!atomic_choice) {}

       ui::Context::removeEventListener(ui::EventType::JOYSTICK_DOWN, &choice_setter);

    }

    switch(choice) { // then it's a normal non-atomic / non-volatile variable
    }
}

Sie landen wahrscheinlich mit einem zusätzlichen Laden der Variablen vs. while(!(choice = shared_choice)) ;, aber wenn Sie eine Funktion zwischen dem Spinloop und ihrer Verwendung aufrufen, ist es wahrscheinlich einfacher, den Compiler nicht zu zwingen, das letzte Leseergebnis in einem anderen lokalen (das es muss möglicherweise verschüttet werden). Oder ich denke, Sie könnten nach dem Deregistrieren ein Finale durchführen choice = shared_choice;, damit der Compiler choicenur ein Register behält und das Atomic oder Volatile erneut liest.

Fußnote 1:volatile

Sogar Datenrennen volatilesind technisch gesehen UB, aber in diesem Fall ist das Verhalten, das Sie in der Praxis bei echten Implementierungen erhalten, nützlich und normalerweise identisch atomicmit memory_order_relaxed, wenn Sie atomare Read-Modify-Write-Operationen vermeiden.

Wann sollte man volatile mit Multi-Threading verwenden? für den Multi-Core-Fall genauer erklärt: im Grunde nie, std::atomicstattdessen verwenden (mit entspannter memory_order).

Vom Compiler generierter Code, der geladen oder gespeichert uint8_twird, ist auf Ihrer ARM-CPU atomar. Lesen/Ändern/Schreiben wie choice++wäre kein atomares RMW auf volatile uint8_t choice, nur eine atomare Ladung, dann ein späterer atomarer Speicher, der auf andere atomare Speicher treten könnte.

Fußnote 2: C++03 :

Vor C++11 sagte der ISO-C++-Standard nichts über Threads aus, aber ältere Compiler funktionierten genauso; C ++ 11 hat im Grunde nur offiziell gemacht, dass die Art und Weise, wie Compiler bereits funktionieren, korrekt ist, indem die Als-ob-Regel angewendet wird, um das Verhalten eines einzelnen Threads nur beizubehalten, es sei denn, Sie verwenden spezielle Sprachfunktionen.

Der Code-Optimierer hat den Code analysiert und nach dem, was er sehen kann, wird sich der Wert von choicenie ändern. Und da es sich nie ändern wird, macht es keinen Sinn, es überhaupt zu überprüfen.

Die Lösung besteht darin, die Variable volatileso zu deklarieren, dass der Compiler gezwungen ist, Code auszugeben, der ihren Wert unabhängig von der verwendeten Optimierungsstufe überprüft.