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 auch volatile 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.


  • Mod

    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:

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


  • Mod

    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 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.


  • Mod

    hustbaer schrieb:

    @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.



  • 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.


  • Mod

    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 und mutable .

    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 😉



  • 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 von volatile ...


  • Mod

    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.pdf

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


Log in to reply