@stoxx
Wenn ein Integer nach deiner Darstellung nicht sicher ist, dann kann auch ein Boolean unsicher sein (hängt davon ab wie ein Boolean intern gespeichert/verarbeitet wird).
>Edit< .. hab meinen vorigen Text nochmal editiert .. genau genommen trifft das in der Tat auch auf booleans zu.
Auch egal, wie er gespeichert, verarbeitet wird, nämlich immer dann, wenn der Wert geprüft wird, und dann vielleicht geändert.
(ist das gleiche Problem, wie unten mit dem increment vom Integer beschrieben)
@
Bei 32bit werden allerdings - soweit mir bekannt - immer genau 4 Bytes (=32bit) bearbeitet, und deswegen ist ein 8/16/24/32bit-Wert auf einem 32bit-Betriebssystem threadsafe, denn die CPU lockt dafür den Speicherplatz (32bit) im Arbeitsspeicher.
das hängt von der CPU ab.
Ein auf dem eigenem Rechner programmiertes und getestes Programm muss noch lange nicht stabil überall funktionieren.
So pauschal kann man das nicht sagen. Es hängt nicht vom Betriebssystem ab, sondern von der CPU (und vom Compiler) ..
Hier mal beispielhaft die Aussagen von Intel
https://software.intel.com/en-us/forums/topic/308940
ich hab auch irgendwo mal eine komplette umfangreiche Liste gefunden, ich werde mal suchen ...
Nicht atomar zu sein heißt ja auch, 2 Threads wollen einen Wert incrementieren.
Beide lesen den Wert 5, und schreiben (leider gleichzeitig) 6 hinein.
Wenn das beide gleichzeitig machen, steht am Ende 6 drin, obwohl 2 Threads zweimal hochgezählt haben und 7 drinstehen müsste.
Daher auch die existierende Windows Funktion InterlockedIncrement ....