volatile Funktionen

Hallo allerseits,

unlängst stieß ich wieder einmal auf ein Thema, zu welchem ich keine befriedigende Antwort fand. Vielleicht weis ja jemand im Forum, warum die Antwort so lautet, wie sie eben lautet...

Frage 1: Warum kann man Memberfunktionen von C++ Klassen volatile deklarieren, nicht-Memberfunktionen (in C++) hingegen nicht?
Kanonisch stellt sich die gleiche Frage für const.

Eine Erklärung über die Adresse der Funktion gelingt nicht wirklich, da auch nicht-Memberfunktionen ge-inlined werden können. Rückwärtskompatibilitätsgründe zu C scheiden hier eigentlich auch als Erklärungsversuch aus.

Frage 2: Welchem Zweck dient diese Art der Deklaration überhaupt (außer einer rein dokumentatorischen)? Ein inline verhindert sie nicht, soll sie ja auch gar nicht!

Schöne Grüße

schnasseldag

Hallo Andreas,

Quote from Andreas

Wenn Du willst, dann hole ich das Buch wieder hervor und zitiere daraus die entsprechenden Aussagen.

Au ja, mach das mal! Wir könnten auch glatt noch telefonieren - bin eh' noch nicht im Bett

Ich habe über die letzten Jahre hinweg das Detail zur neusten Entwicklung des Standards verloren. Den letzten größeren Schlag gab's m.E. im C++ 11 Release, in dem Lambdas und Compileroptimierungen zur Objektübergabe von Funktionen definiert wurden. Dumm nur, wenn die Compilerhersteller nicht mit den Implementierungen nachkommen... und man selber nicht mit dm Lesen :s

Ich war jahrelang ein absoluter Verfechter von C++ und mein Hals schwoll an, wenn jemand daherkam und sagte "C++ würde gegenüber C zu viel Overhead erzeugen und wäre hernach nicht für embedded Entwicklungen geeignet". Das ist Unfug und zeugt nur davon, daß man sich nie mit Compiler, Linker und Codegenerator beschäftigt hat. Bereits der VS 6 C++ Compiler erkannte bei Templateinstanzen der gleichen Typgröße Ähnlichkeiten und hat Codedupletten vermieden. Der Linker hat sie dann über Module hinweg aus dem obj-Code entfernt, sodaß nur eine Codeinstanz im exe übrig blieb. Da muß ich sagen: "Hut ab". Der GCC hingegen legte seinerzeit Code für ARM-Prozessoren an, der im ARM und Thumb Mode schneller lief, wenn man auf die obere Hälfte der Register verzichtete. Das ist ein Witz, aber leider traurige Wahrheit. Mittlerweile sind mehr als 10 Jahre in's Land gegangen und die Karten wurden neu gemischt. Dennoch, man kann sagen, was man will. C# ohne Header und mit seiner Sprachgestaltung hat seinen Reitz. Man mag über Reflection dabettieren ob es nun effizient sei oder nicht (wieviel Code muß eigentlich wirklich effizient implementiert sein?) - es kann etliche Zeilen Code sparen wenn man es richtig einsetzt. Der Garbagecollector - nun, daß war wohl eher ein Schuß nach hinten, zumindest wenn man aus der embedded Welt kommt. Aber auch für für größere Applikationen mit zeitkritischen Komponenten stellt er wohl eher ein Hindernis dar, als das er hilft... Der zuverlässige Aufruf einer ~ vor dem Klassennamen ist noch immer ungeschlagen!

So, ich hüpfe jetzt doch so langsam in's Bett

Grüßle in den Westen

schnasseldag

@deets

// Geschrieben
void meineMethode() {
  for(int i=0; i < 10; i++) {
       if(i == this.mEinMember) {
             // tu was!
       }   
  }
}

// Vom Compiler optimiert
void meineMethode() {
  $register = this.mEinMember;
  for(int i=0; i < 10; i++) {
       if(i == $register) {
             // tu was!
       }   
  }
}

Das Beispiel leuchtet ein. Genau dafür mache ich ja eine Member-Methode volatile. Was mir jedoch für C++ (über Python kann ich nichts sagen) nicht einleuchtet, ist die Erklärung des this Pointers.
In C++ würde ein volatiles Objekt erst während seiner Instanzieierung zu einem solchen gemacht werden. Also
volatile CMyClass c;
In einem Rutsch werden dann alle Member volatile. Das ergibt auch Sinn, weil der Implementierer der Klasse nicht immer weis, wie sein Objekt eingesetzt wird. Insofern paßt dann aber die Erklärung mittels this-Pointer für Nicht-Memberfunktionen nicht mehr... Ist echt verhext - gell?

Es ist natürlich richtig, daß volatile und inline zunächst orthogonal zueinander stehen. Allerdings macht es durchaus Sinn kurze Getter- Setter-Funktionen zu inlinen, die Ihrerseits dann auf volatile Member zugreifen. Insofern kann der Compiler dann den Prolog/Epilog weglassen (sprich den Funktionsaufruf wegoptimieren) und auf die Adresse der Variable zugreifen. Das widerspricht Deiner Aussage in keiner Weise, soll jedoch verdeutlichen, daß solcherart Konstrukte durchaus in Paarung auftreten können...
Automatisch zusammengefügt:[hr]

Quote from pgloor

Weil das Schlüsselwort "volatile" eben nicht nur dokumentatorische Zwecke erfüllt, sondern, wenn falsch und unnötig eingesetzt, auch erhebliche Auswirkungen auf die Performance haben kann.

pgloor: Du beziehst Dich auf die Verwendung des Schlüsselwortes volatile auf Daten, nicht auf Funktionen. Da hast Du natürlich Recht. Meine Frage 2 zielte jedoch auch auf die Verwendung für Funktionen ab. Sorry, da war ich wohl nicht ganz präzise.

...
volatile CMyClass c;
...

Quote from schnasseldag

In einem Rutsch werden dann alle Member volatile.

Da hätte ich wohl besser schreiben sollen "In einem Rutsch werden dann alle Member-Variable volatile."

Das ich für ein volatiles Objekt lediglich nur noch volatile Funktionen aufrufen kann - hm, das hat man offenbar so festgelegt (wußte ich allerdings bis eben auch nicht). Eine Begründung (außer einer dokumentatorischen) erschließt sich mir jedoch noch immer nicht. :s
Aber noch mal zurück zur Ausgangsfrage - wieso können Memberfunktionen volatile sein, Nicht-Member jedoch nicht. Letztendlich geht es um Daten, die seiteneffektfrei gelesen bzw. geschrieben werden sollen. Wie der Code realisiert wird, ist doch zunächst sekundär?! Eine volatile Member-Funktion, die eine nicht volatilen Member-Variable schreibt/liest, ist so überflüssig wie ein Kropf. Das volatile hinter der Member-Funktion schützt die Variable nicht davor, in einem Register zu landen.

Quote from __deets__

Versuchen wir es noch einmal: Eine volatile Methode behandelt die Member eines Objektes als volatile Daten. Das ist *ALLES* worum es geht. Die Member erreicht man durch this, und darum bezieht sich das volatile - genauso wie ein const - auf den this-Pointer.

Der Bezug volatiles im Kontext einer Funktion zu this war mir nicht klar. Mit const springt es einen jedoch direkt an. Ich hab' das unten noch mal an einem Beispiel verdeutlicht. Der Zugriff von baa() auf den Member x des Objektes c1 zeigt recht deutlich, daß das nicht volatile x dennoch volatile durch this betrachtet wird.

Quote from __deets__

Ob du ein Objekt von aussen volatile erklaerst, und dort endlos auf seinen Membern rumfuhrwerkst, hat damit nichts zu tun - da geht es um den Code, der von *AUSSEN* auf die Member zugreift (Member meint hier Daten, nicht Methoden).

Vielleicht verstehe ich Dich hier nicht, oder Du irrst in diesem Punkt. Beispiel: c2 ist in sich ein volatiles Objekt. Mithin sind Zugriffe (egal ob über baa() oder direkt über die Membervariable c2.x) auf die nicht volatile Membervariable c2.x dennoch volatile. Die Art des Zugriffs von außen ist damit egal (ebenfalls, ob ein Member innerhalb der Klasse volatile deklariert wurde oder nicht).
Im umgekehrten Fall von c1 hingegen werden alle Zugriffe auf den nicht volatilen Member c1.x wegoptimiert (egal ob über foo() oder von außen per c1.x-Zugriff).

class CMyClass
{
public:
    int    x;
    volatile int y;
    void foo()
    {
        x = 1;
        x = 2;
        y = 3;
        y = 4;
    }
    void baa() volatile
    {
        x = 5;
        x = 6;
        y = 7;
        y = 8;
    }
};




int _tmain(int argc, _TCHAR* argv[])
{
00401000  sub         esp,8 
    CMyClass c1;
    c1.x = 9;
    c1.x = 10;
    c1.y = 11;
00401003  mov         dword ptr [esp+4],0Bh 
    c1.y = 12;
0040100B  mov         dword ptr [esp+4],0Ch 
    c1.foo();
00401013  mov         dword ptr [esp+4],3 
0040101B  mov         dword ptr [esp+4],4 
    c1.baa();
00401023  mov         dword ptr [esp],5 
0040102A  mov         edx,6 
0040102F  mov         dword ptr [esp],edx 
00401032  mov         ecx,7 
00401037  mov         dword ptr [esp+4],ecx 
0040103B  mov         eax,8 
00401040  mov         dword ptr [esp+4],eax 


    volatile CMyClass c2;
    c2.x = 13;
00401044  mov         dword ptr [esp],0Dh 
    c2.x = 14;
0040104B  mov         dword ptr [esp],0Eh 
    c2.y = 15;
00401052  mov         dword ptr [esp+4],0Fh 
    c2.y = 16;
0040105A  mov         dword ptr [esp+4],10h 
    c2.baa();
00401062  mov         dword ptr [esp],5 
00401069  mov         dword ptr [esp],edx 
0040106C  mov         dword ptr [esp+4],ecx 
00401070  mov         dword ptr [esp+4],eax

Quote from __deets__

Und damit ist auch klar, warum nur Methoden volatile sein koennen. So wie auch const. Nur Methoden haben einen impliziten this-Pointer. Alle anderen Daten, auf die sie zugreifen - Parameter, statische Variablen, lokale Variablen - koennen explizit mit volatile gekennzeichnet sein. Das volatile-Schluesselwort bezieht sich also auf this.

Jein, so richtig leuchtete (näheres weiter unten) mir immer noch nicht ein, weshalb man bei Nicht-Memberfunktionen nicht doch auch ein volatile hinten anstellen können sollte. Klar, einen this-Pointer gibt's hier nicht aber warum nicht sinngemäß alle außerhalb der Scope der Funktion deklarierte (und innerhalb der Funktion verwendete) Variable einfach innerhalb der Funktion als volatile behandeln? Das entspräche einer "ähnlichen" Behandlung wie der bei Memberfunktionen. Anstelle des this-Kontext tritt eben der Modulkontext, in dem sich die Funktion befindet?!

Geht aber tatsächlich nicht. Hierzu ein etwas "bekranktes" Beispiel über const.

Die const Memberfunktion definiert ja, das Objekt nicht zu modifizieren. Schön und gut. Nur außerhalb des this-Pointers darf auch die const-Memberfunktion lustig Seiteneffekte verursachen. Insofern besitzt die Memberfunktion zwei Bezüge. Den des this und den zur Außenwelt. Nachdem der Nicht-Memberfunktion der this-Freiheitsgrad fehlt, würde sich die const-Aussage (sinngemäß auch volatile-Aussage) also auf alle außerhalb der Funktion deklarierte Variable beziehen müssen. Damit entstünde jedoch eine semantische Ungleichbehandlung des Schlüsselwortes volatile für Memberfunktionen und Nicht-Memberfunktionen für den globalen Namensraum. Und vermutlich wollte man gerade das vermeiden.

@deets: Danke - hast mir sehr auf die Sprünge geholfen. Wenngleich ich wohl doch dabei bleibe meine Member-Variable zu volatilen, als mit den Funktionen herumzuoperieren. Wenn ein Datum volatile ist, dann ist es daß eben. Warum dann also "gemischt" mittels volatiler und nicht-volatiler Funktionen darauf rumfuhrwerken?! Mir fehlt da selbst gerade der Anwendungsfall - aber darum ging es ja auch gar nicht in meiner ursprünglichen Fragestellung....

Quote from __deets__

Letztlich ist volatile als Konzept eh nicht mehr zeitgemaess, weil es eine viel zu simple und schlecht definierte Semantik hat. So verhindert volatile zB nicht, dass der Prozessor ein instruction-re-ordering vornimmt. Das ist aber fuer concurrency-programmierung, wo man ja eben genau volatile einsetzt, eh ein Problem.
In C++ solltest du also sowieso auf die neuen <atomic>-Primitive zurueckgreifen - die sind eh maechtiger.

Klar, Codeumstellung, Reentranz, Synchronisierung oder auch nur Datenintegrität sind über volatile allein nicht zu erschlagen. Auch Memorybarriers haben damit nix zu tun. Atomare Operationen müssen allerdings auch von Compiler und Runtime unterstützt werden. Die vorgenannten Gedanken kamen mir während ich auf dem Atmega328 programmierte. Der hat einen sehr einfache Interruptstruktur und die Synchronisationsprimitive heißen da cli und sei Auf der Ebene muß man sich dann allerdings wieder Gedanken um volatile machen. Auf Applikationsebene andererseits will ich davon nix wissen - völlig Deiner Meinung.

PS: Ich weis schon, daß Scope {} eine andere Bedeutung hat, mir fiel nur kein passenderes Wort ein.