volatile / const volatile Memberfunktionen
-
volatile wird ja extrem selten verwendet. Wann sollte man eine Memberfunktion volatile bzw const volatile machen?
-
Eine Methode die
volatile
ist kann nur bei Objekten die auchvolatile
sind aufgerufen werden.
-
Das weiß ich. Aber ich will wissen, wann sowas überhaupt Sinn macht.
-
Da gibt es was, um bei Multithreading durch nicht-volatile zu kennzeichnen, daß ein Objekt gelockt ist, wobei die globale Variable dann an sich volatile ist.
-
314159265358979 schrieb:
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:
-
volatile im Zusammenhang mit Klassenobjekten macht wenig Sinn (außer evtl bei POD-Klassen).
Abgesehen davon, dass nicht ganz klar ist was - außer Zugriffen auf einzelne Member - noch einen Zugriff auf das Objekt darstellt, und somit beobachtbar ist, hat ein solches Objekt die unangenehme Eigenschaft, dass es im Prinzip über keinerlei Invarianten verfügt (ggf. abgesehen von solchen, die jeweils nur ein einzelnes Member betreffen). Dann stellt sich alleridngs die Frage, welches Konzept eigentlich durch so ein Objekt gekapselt wird.
-
EOutOfResources schrieb:
Eine Methode die
volatile
ist kann nur bei Objekten die auchvolatile
sind aufgerufen werden.nurauchGleich wie bei
const
halt. Ein Objekt muss ja auch nichtconst
sein, damit ich neconst
Methode aufrufen kann. Es darfconst
sein.@SeppJ:
314 hat gefragt wann Memberfunktionenvolatile
sein sollten. Das hat mit Memory Mapped IO etc. nixe zu tun@volkard:
Ja, das kenn ich auch. Man macht das Objektvolatile
, verpasst der Klasse Lock/Unlock Methoden, und verwendet dann Hilfsklassen um das Objekt zu locken und gleichzeitig dasvolatile
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 mitvolatile
versehen. Einfach zu Dokumentationszwecken.
-
hustbaer schrieb:
@SeppJ:
314 hat gefragt wann Memberfunktionenvolatile
sein sollten. Das hat mit Memory Mapped IO etc. nixe zu tunIch 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.
-
SeppJ schrieb:
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.
-
volkard schrieb:
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.
-
Vielleicht war die Variable
volatile
undmutable
.Aber ich sehe immern noch keine Memberfunktionen.
Denn auchvolatile 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
-
Man könnte also zusammenfassend sagen, dass man volatile Memberfunktionen zur markierung von Thread-safen Funktionen verwenden könnte? Werden dadurch nicht Optimierungen verhindert?
-
volatile
hat NICHTS mit Thread-Safety zu tun. Das ist leider ein sehr weit verbreiteter Irrglaube. Und ja,volatile
verhindert Optimierungen, genau das ist eigentlich der Zweck vonvolatile
...
-
dot schrieb:
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.pdfIm Anhang ist auch eine Erklärung über den Sinn von volatile (Variablen!), aber das wurde im Thread schon genannt.