mir ist klar dass volatile auf multi-core für thread-sicheren Zugriff nicht geeignet ist. Wie sieht es aber bei einem volatile zwischen fences auf einem single-core aus? Hier können doch ebenfalls interrupts passieren und damit meherere Zugriffe auf eine variable zwischen den fences kaputt machen. Wenn ich aber nur einen einzigen schreibzugriff zwischen den fences habe, ware dann die Deklaration der variable als volatile sicher bezüglich interrupts?

Danke

Single core? Was ist das denn für eine veraltete Technologie?

Vielleicht ist dein Fall vom Standard abgedeckt und immer threadsafe. Das hätte dann gar nichts mit der Anzahl der Kerne zu tun.

Wenn es undefiniertes Verhalten ist, hängt es vom Compiler ab, ob dein Fall sicher ist.

Wenn du wirklich nur "einen einzigen Schreibzugriff" hast und sonst keine gleichzeitigen Zugriffe, ist es doch sowieso sicher. Was ist das vollständige Problem?

Wie sieht es aber bei einem volatile zwischen fences auf einem single-core aus?

volatile ist hier weder nötig noch hinreichend.
Nicht nötig, weil du ja sowieso die Fences hast. Und nicht hinreichend, weil volatile nicht garantiert dass die Zugriffe atomar erfolgen.

Wenn du z.B. auf ner 32 Bit CPU nen volatile long long (=min. 64 Bit) schreibst, dann kann es leicht sein dass der Compiler zwei oder mehr Instruktionen daraus macht. Z.B. weil die CPU einfach keine Operation hat mit der man 64 Bit Werte auf einmal lesen oder schreiben kann. Das ist dann nicht mehr atomar. Auch auf Single-Core nicht. (Ich gehe mal davon aus dass wir keine Interrupts disablen oder ähnliche krasse Eingriffe vornehmen.)

uitob schrieb:

Hier können doch ebenfalls interrupts passieren und damit meherere Zugriffe auf eine variable zwischen den fences kaputt machen.

Das sowieso, ja. Wenn es um mehr als einen einzigen Zugriff geht, dann kann da immer was dazwischenpfuschen.

uitob schrieb:

Wenn ich aber nur einen einzigen schreibzugriff zwischen den fences habe, ware dann die Deklaration der variable als volatile sicher bezüglich interrupts?

Nein, siehe Erklärung oben.
volatile impliziert nicht atomic (und atomic impliziert nicht volatile ).

Verwende einfach die selben Konstrukte wie du sie auch auf Multi-Core Systemen verwenden würdest.
Wenn der Compiler weiss dass das System Single-Core ist, und dass man daher bestimmte Dinge mit weniger Overhead machen kann, dann wird er hoffentlich schlau genug sein entsprechend "billigen" Code zu erzeugen.

Oder du richtest dich nach dem was die die Plattform (CPU + OS + Compiler) garantiert. Dann hast du zwar plattformabhängigen Code, aber so lange du auf dieser Plattform bleibst ist natürlich trotzdem garantiert dass es funktioniert. Und was genau dir die Plattform garantiert, das kann dir nur die Plattform sagen.

Jetzt meine Frage: scheinbar benutzt microsoft hier doch volatile zwischen barriern? Kann jemand hierzu noch eine Stellung nehmen (auch im Hinblick zu oben)? Warum klappt das dann scheinbar doch hinsichtlich Thread-Sicherheit?

->

Wenn man sich auf compilerspezifische Dinge verlassen will, dann kann man mit volatile je nach Compiler schon viel anfangen. Hab ich ja bereits geschrieben.