Das weiß ich. Aber ich will wissen, wann sowas überhaupt Sinn macht.

Erster Google Treffer schrieb:

The volatile keyword is a type qualifier used to declare that an object can be modified in the program by something such as the operating system, the hardware, or a concurrently executing thread.

Und das sind die Falle wo so etwas benutzt wird. Guck dir z.B. mal das Prinzip von Memory-Mapped-IO an und stell dir vor, was passieren würde, wenn der Compiler anfängt an Zugriffen auf solche Speicherbereichen herumzuoptimieren:

http://en.wikipedia.org/wiki/Memory-mapped_I/O

Eine Methode die volatile ist kann nur bei Objekten die auch volatile sind aufgerufen werden.

nur auch

Gleich wie bei const halt. Ein Objekt muss ja auch nicht const sein, damit ich ne const Methode aufrufen kann. Es darf const sein.

@SeppJ:
314 hat gefragt wann Memberfunktionen volatile sein sollten. Das hat mit Memory Mapped IO etc. nixe zu tun

@volkard:
Ja, das kenn ich auch. Man macht das Objekt volatile , verpasst der Klasse Lock/Unlock Methoden, und verwendet dann Hilfsklassen um das Objekt zu locken und gleichzeitig das volatile wegzucasten. Hab ich aber noch nie irgendwo angewendet gesehen.

Bei solchen Klassen könnte man dann Funktionen, die aus allen Threads ohne Locking aufgerufen werden dürfen, volatile machen. Damit man sie ohne Locking und ohne Cast aufrufen kann. Sowas gibt's ja öfters mal, z.B. Getter die konstante Werte zurückgeben (z.B. die ID des Threads der ein GUI-Control "besitzt") oder die "Cancel"/"IsCanceled" Methoden einer "Job" Klasse.

Obwohl ich diese Verwendung von volatile (auf Objekte) wie gesagt noch nie gesehen habe, könnte man trotzdem Methoden die ohne Locking von überall aus "safe" sind mit volatile versehen. Einfach zu Dokumentationszwecken.

@SeppJ:
314 hat gefragt wann Memberfunktionen volatile sein sollten. Das hat mit Memory Mapped IO etc. nixe zu tun

Ich sollte genauer lesen.

Ich erinnere mich dunkel, mal so etwas gehabt zu haben. Da ging es um ein Implementierungsdetails, welches sich ändern konnte, ohne dass der beobachtbare Zustand des Objekts sich änderte. Irgendeine interne Statistik glaube ich. Ist leider zu lange her um genaueres zu sagen und ein kurzes grep auf meinem src-Ordner sagt mir, dass ich das Programm nicht mehr habe.

Ich erinnere mich dunkel, mal so etwas gehabt zu haben. Da ging es um ein Implementierungsdetails, welches sich ändern konnte, ohne dass der beobachtbare Zustand des Objekts sich änderte. Irgendeine interne Statistik glaube ich. Ist leider zu lange her um genaueres zu sagen und ein kurzes grep auf meinem src-Ordner sagt mir, dass ich das Programm nicht mehr habe.

Eigentlich glaube ich Dir nicht, daß Du es verwechselt. Aber die Beschreibung klingt fast nach mutable.

Eigentlich glaube ich Dir nicht, daß Du es verwechselt. Aber die Beschreibung klingt fast nach mutable.

Kann's auch gewesen sein. Ist lange her, sind beides Sachen die man selten braucht. Aber eher volatile, war nämlich etwas was ein anderer Prozess gelesen hat um etwas über den Programmverlauf zu erfahren.

Aber ich sehe immern noch keine Memberfunktionen.
Denn auch volatile const Memberfunktionen können keine nicht- mutable Member ändern.
Und eine nur- volatile Memberfunktionen kann das genau so gut, wie es eine normale (non- const non- volatile ) Memberfunktionen kann

volatile hat NICHTS mit Thread Safety zu tun. Das ist leider ein sehr weit verbreiteter Irrglaube...

Ja, Meyers und Alexandrescu haben das mal hübsch erklärt:
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

Im Anhang ist auch eine Erklärung über den Sinn von volatile (Variablen!), aber das wurde im Thread schon genannt.