Thread safety / Atomarer Zugriff auf primitive Datentypen
-
dot schrieb:
SchlechterInformatiker schrieb:
Und was ist mit Zeigern? Wird eine Anweisung wie
*i = 5;aufgeteilt in eine Dereferenzierung und eine Zuweisung oder ist das auch nur eine Maschinenanweisung, die nicht unterbrochen werden kann?
Auch hier wieder: Hängt davon ab. Evtl. muss z.B. zuerst die Adresse gelesen werden...
[/quote]
Wo wir gerade dabei sind: Im zitierten Programming Guide ist übrigens nur die Rede von Speicherzugriffen. Es gibt Instruktionen, die haben sowohl Lese- als auch Schreibzugriffe. Natürlich wird der Prozessor nicht unterbrochen, wenn er mitten in einer Instruktion steckt. Deswegen heisst es aber noch lange nicht, dass sich in einer Mehrprozessorumgebung zeitlich ein anderer Prozessor zwischen die Speicherzugriffe schieben könnte.
-
merano schrieb:
dot schrieb:
Die Aussage dass bool atomar wäre macht keinen Sinn. Und Operationen auf einem bool oder int oder sonstwas sind im Allgemeinen ganz gewiss nicht atomar.
Im Prinzip richtig!
Laut Intel gibt es "basic memory operations" die atomar sind. Leider können Hochsprachenbefehle aber aus mehreren Maschinenbefehlen bestehen.
Natürlich ist auf Maschinenebene ganz klar definiert was atomar ist und was nicht. Aber hier gehts um C++ und da ist das eben nicht definiert und man sollte daher auch keine Annahmen über solche Dinge treffen
-
Aaah Thread-Safety! Ich war gerade dabei meinen letzten Post zu editieren...
Können Programmabstürze vorkommen?
-
[quote="SchlechterInformatiker"]Ok, und was ist denn nun mit Zuweisungen? Sind die atomar?
Steht doch alles in dem posting von Merano:
Guaranteed Atomic Operations
The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always
be carried out atomically:
. Reading or writing a byte
. Reading or writing a word aligned on a 16-bit boundary
. Reading or writing a doubleword aligned on a 32-bit boundary
The Pentium processor (and newer processors since) guarantees that the following
additional memory operations will always be carried out atomically:
. Reading or writing a quadword aligned on a 64-bit boundary
. 16-bit accesses to uncached memory locations that fit within a 32-bit data bus
The P6 family processors (and newer processors since) guarantee that the following
additional memory operation will always be carried out atomically:
. Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line[quote="SchlechterInformatiker"]
Oder kann da sogar ein Programmabsturz vorkommen wenn ein Thread während des Zugriffs auf eine Variable unterbrochen wird (nicht dass ich das bisher hätte, will aber trotzdem sicher gehen und vorbeugen)?Wie denn das bitte?
Wir reden hier doch von atomaren Operationen in dem Sinn wie es Mearon schreibt. Wie soll überhaupt so etwas einen Programmabsturz verursachen?
-
x86 schrieb:
Natürlich wird der Prozessor nicht unterbrochen, wenn er mitten in einer Instruktion steckt. Deswegen heisst es aber noch lange nicht, dass sich in einer Mehrprozessorumgebung zeitlich ein anderer Prozessor zwischen die Speicherzugriffe schieben könnte.
genau. 100 Punkte. (s.o.)
-
@Martin Richter: Weiß ich nicht... das frage ich mich auch. Bei atomaren Operationen natürlich nicht. Deiner Antwort entnehme ich, dass das nicht vorkommen kann. Aber was gilt als atomare Operation und was nicht?
Bezüglich des Postings von Merano:
Da steht "The Intel486 processor"... was ist wenn aber mein Programm auf einem AMD oder sonst was läuft?
-
Hallo dot,
Aber hier gehts um C++
Jetzt bin ich spitzfindig
Hier gehts ganz klar um MFC(Visual C++) und daher um Windows.
Herzliche Grüsse
Walter
-
Nur um es nochmal ganz klar und deutlich zu sagen: Es ist nicht definiert ob und unter welchen Umständen irgendwelche Operationen in C++ atomar sind oder nicht und daher kannst du dich nicht drauf verlassen. Period.
Wenn du atomare Operationen brauchst, dann musst du dich entsprechender Primitive bedienen, wie z.B. die erwähnten Funktionen der WinAPI oder irgendwelche Compiler Intrinsics oder sonstwas. C++11 bietet auch atomics in der Standardlibrary, die sind nur noch nicht überall verfügbar.
-
weicher schrieb:
Hier gehts ganz klar um MFC(Visual C++) und daher um Windows.
Point taken. Das ändert aber nix.
-
Ok, solange mein Programm nicht abstürzt weil zwei Threads gleichzeitig auf eine Variable lesend/schreibend zugreifen, ist alles in Ordnung.
Veraltete Werte machen mir nicht aus. Dann wird halt erst im nächsten Zyklus aktualisiert.
Ansonsten synchronisiere ich.
Danke!
-
SchlechterInformatiker schrieb:
Bezüglich des Postings von Merano:
Da steht "The Intel486 processor"... was ist wenn aber mein Programm auf einem AMD oder sonst was läuft?Ich glaube nicht, das es sich ein Hersteller leisten kann dazu NICHT kompatibel zu sein.
Wenn du es genau wissen musst: Auch AMD gibt schöne References raus; ebenfalls kostenlos ...
Was wäre denn sonstwas ?
Wir sprechen hier konkret von Windows (genauer: MFC ...
-
merano schrieb:
Was wäre denn sonstwas ?
Windows läuft aber auf den verschiedensten Plattformen (x86, x64, IA64, ARM, ...)
Und außerdem hängt es vom jeweiligen Code und davon was genau der Compiler draus macht ab. Selbst wenn man sich auf Windows, x86 und MSVC festlegt, kann man immer noch keine allgemeinen Aussagen über solche Dinge machen.
-
SchlechterInformatiker schrieb:
Ok, solange mein Programm nicht abstürzt weil zwei Threads gleichzeitig auf eine Variable lesend/schreibend zugreifen, ist alles in Ordnung.!
Ich glaube Du hast es immer noch nicht ganz verstanden. Ein Programm stürzt _niemals_ ab weil 2 oder mehr Threads gleichzeitig irgendwas tun. Durch das "gleichzeitige" tun können aber Daten korrumptiert werden, die dann zu Abstürzen führen. Hat dot aber schon geschrieben.
Falls Du es nur falsch beschrieben hast und trotzdem das richtige meintest: Solche Spitzfindigkeiten sind bei Multithreading sehr wichtig. Du siehst ja selbst der Pfad der Gerechten (= was man tun darf und was nicht) ist sehr schmal.
-
SchlechterInformatiker schrieb:
Ok, solange mein Programm nicht abstürzt weil zwei Threads gleichzeitig auf eine Variable lesend/schreibend zugreifen, ist alles in Ordnung.
Wollte damit nur sagen dass mir jetzt klar ist, dass ein Programm wegen sowas nicht abstürzen kann. Und dass es wegen inkonsistenten Daten dennoch abstürzen kann ist eh klar.
-
SchlechterInformatiker schrieb:
Bezüglich des Postings von Merano:
Da steht "The Intel486 processor"... was ist wenn aber mein Programm auf einem AMD oder sonst was läuft?Auch das habe ich schon geschrieben:
Das ist Standard für alle x86, x64 kompatiblem Prozessoren und genug andere auch.
Wie sollte esauch anders sein, bei den entsprechenden Busbreiten....
-
Ok, danke an alle!
