ThreadPool - Boost.Thread
-
hustbaer schrieb:
volatile ist für ein Cancel-Flag praktisch gesehen ausreichend. Für ein Cancel-Flag brauche ich weder atomare Zugriffe noch Memory-Ordering. Wichtig ist nur dass die Änderung des schreibenden Threads irgendwann mal für andere Threads sichtbar wird, und dass der lesende Thread nie "true" liest, obwohl keiner jemals "true" reingeschrieben hat.
Dann lass das volatile in Zukunft weg und du wirst sehen, es funktioniert trotzdem.
-
nurf schrieb:
hustbaer schrieb:
volatile ist für ein Cancel-Flag praktisch gesehen ausreichend. Für ein Cancel-Flag brauche ich weder atomare Zugriffe noch Memory-Ordering. Wichtig ist nur dass die Änderung des schreibenden Threads irgendwann mal für andere Threads sichtbar wird, und dass der lesende Thread nie "true" liest, obwohl keiner jemals "true" reingeschrieben hat.
Dann lass das volatile in Zukunft weg und du wirst sehen, es funktioniert trotzdem.
Das tut es nur, wenn der Code in der Schleife für den Compiler zu kompliziert wird, so dass er nichtmehr sicher sein kann, dass das Cancel-Flag nicht irgendwo geändert werden könnnte.
Das funktioniert z.B. nicht:
while (!cancelFlag);Hier erkennt der Compiler dass cancelFlag in der Schleife nicht verändert wird, und zieht den Test "!cancelFlag" aus der Schleife raus.
volatile verhindert das.Wieso ich damit pokern sollte dass der Compiler die mögliche (und durch das fehlende volatile erlaubte) Optimierung nicht findet, weiss ich nicht.
-
Also entweder verwechselst du da was mit Java oder C#.
Soll mir egal sein, im Internet findet sich genug zu der Thematik.
Noch ein Zitat zum Abschluss:
If your multithreaded code works properly with volatile and doesn’t work without, then either your C++ implementation carefully implemented volatile to work with threads (less likely), or you simply got lucky (more likely).
-
Ich verwechsle nichts, und ich kenne auch die diversen Zitate, Artikel etc.
Volatile in C bzw. C++ zwingt den Compiler dazu, eine load bzw. store Instruction zu erzeugen. Nicht mehr und nicht weniger.
Um den Rest kümmert sich in diesem Fall die CPU, da, wie ich schon geschrieben habe, Speicher-Sichtbarkeit etc. für ein Cancel-Flag vollkommen wurscht sind. Genauso ob der Zugriff atomar erfolgt oder nicht.
Das ist einer der wenigen Spezialfälle, wo man in C bzw. C++ mit volatile, ohne zusätzliche, "freiwillige" Garantien des Compilers, etwas Sinnvolles anstellen kann.
Vorausgesetzt man hat eine CPU, die die Caches *irgendwann mal* selbst updated, ODER ein Betriebssystem welches hin und wieder mal etwas macht was die Caches flusht. Und ich schätze dass das jedes OS welches Threads verwendet tut, nämlich wenn der Scheduler anläuft um zu gucken ob auf einen anderen Thread umgeschaltet werden sollte.
Ich weiss dass es keine vom Standard garantierte Sache ist. Ich sage nur: es funktioniert so-gut-wie überall, wenn nicht überhaupt überall.
