Ist die Selbstinkremente in C threadsicher?

Question

ich einige Code in FreeRTOS (FreeRTOSV7.4.0 \ FreeRTOS \ Source \ tasks.c) gefunden:

void vTaskSuspendAll(void) 
{ 
    /* A critical section is not required as the variable is of type 
    portBASE_TYPE. */ 
    ++uxSchedulerSuspended; 
} 

Es wird ausdrücklich gesagt, keine Notwendigkeit, aufgrund der Art zu schützen ist "portBASE_TYPE", die ein " lang "tippen. Mein Verständnis ist, dass es davon ausgeht, dass das Selbstinkrement zu diesem Typ atomar ist. Aber nachdem ich es auseinander genommen habe, konnte ich keinen Beweis finden, es ist eine einfache Last-> hinzufügen-> speichern. Dann ist es ein Problem?

void vTaskSuspendAll(void) 
{ 
     /* A critical section is not required as the variable is of type 
     portBASE_TYPE. */ 
     ++uxSchedulerSuspended; 
4dc: 4b03   ldr  r3, [pc, #12] ; (4ec <vTaskSuspendAll+0x10>) 
4de: f8d3 2118  ldr.w r2, [r3, #280] ; 0x118 
4e2: 1c50   adds r0, r2, #1 
4e4: f8c3 0118  str.w r0, [r3, #280] ; 0x118 
4e8: 4770   bx  lr 
4ea: bf00   nop 
4ec: 00000000  .word 0x00000000 

000004f0 <xTaskGetTickCount>: 
     return xAlreadyYielded; 
} 

Answer 1

Nein, die Erhöhung der Werte in C ist nicht garantiert atomar. Sie müssen eine Synchronisierung bereitstellen oder eine systemspezifische Bibliothek zum Ausführen atomarer Inkremente/Dekremente verwenden.

Answer 2

Es ist nicht atomar, wie Sie dokumentiert haben. Aber es könnte immer noch "threadsicher" in einem weniger strengen Sinne sein: Ein long kann nicht in einem inkonsistenten Zustand sein. Das Ausmaß der Gefahr hierbei ist, dass, wenn n Fäden vTaskSuspendAll rufen dann uxSchedulerSuspended von irgendwo zwischen 1 und n erhöht werden.

Dies könnte sich aber völlig in Ordnung sein, wenn die Variable ist etwas, das nicht perfekt sein muss, wie ein Tracker, wie oft der Benutzer zu suspendieren gefragt. Es gibt "thread safe" was bedeutet "diese Operation erzeugt das gleiche Ergebnis, egal wie ihre Aufrufe verschachtelt sind" und es gibt "thread safe" was bedeutet "nichts explodiert, wenn Sie dieses aus mehreren Threads aufrufen".

Answer 3

Der Vorgang ist nicht atomar, aber es nirgendwo sagt es ist. Der Code ist zwar threadsicher, aber Sie müssen sehr gut mit dem Code vertraut sein und wissen, wie er in das Design des Schedulers eingepasst wurde. Es spielt keine Rolle, ob andere Tasks die Variable zwischen Laden und Speichern ändern, denn wenn der ausführende Task als nächstes ausgeführt wird, findet er die Variable in demselben Zustand wie beim ursprünglichen Laden (also sind die Modifikations- und Schreibabschnitte immer noch konsistent und gültig)).

Als vorherige geschrieben Notizen kann die lange nicht in einem inkonsistenten Zustand sein, weil es der Basistyp der Architektur ist, auf dem es läuft. Bedenken Sie jedoch, was passiert, wenn der Code auf einer 8-Bit-Maschine (oder 16 Bit) läuft und die Variable 32 Bit hat. Dann wäre es nicht threadsicher, weil die vollen 32 Bits gleichzeitig Byte oder Wort geändert würden und nicht alle auf einmal. In diesem Szenario könnte ein Byte in ein Register geladen, modifiziert und dann in den RAM zurückgeschrieben werden (wobei die anderen drei Bytes unverändert gelassen werden), wenn ein Kontextwechsel auftritt. Wenn die nächste auszuführende Task dieselbe Variable liest, würde sie ein Byte lesen, das geändert wurde, und drei Bytes, die nicht geändert wurden - und Sie haben ein großes Problem.

Grüße, Richard (http://www.FreeRTOS.org)