Was genau bewirkt volatile - Concurency?

3 Antworten

Vom Fragesteller als hilfreich ausgezeichnet

Das volatile-Schlüsselwort bezieht sich auf den Bereich INNERHALB des Programms. Es teilt dem Compiler mit, dass der so deklarierte Wert "flüchtig" ist, d. h. sich zwischen zwei Abfragen geändert haben kann.

Wenn das Programm nach dem Wert der flüchtigen Variablen fragt, bekommt es natürlich den gerade aktuellen Wert.

Aber wenn der Compiler nichts davon weiß, dass irgendein anderen Prozess/Thread diesen Wert geändert haben könnte, geht er davon aus, dass sich der Wert zwischendurch nicht geändert hat. Da Compiler üblicherweise ziemlich viel optimieren dürfen, wird eine zweite Abfrage eines Wertes regelmäßig einfach wegoptimiert.

Danke an pcjobnet für den Link - spart mir die Recherche, ob volatile in Java dieselbe Bedeutung hat wie üblich (hat es).

-----

Ein Beispiel, das mir im Gedächtnis geblieben ist: da hat sich jemand gewundert, wieso

bool someExternalValue /* hier wird irgendwie auf eine externe Speicherzelle referenziert, weiß nicht mehr, wie */;

while (someExternalValue) {
    // do something
}

ersetzt wurde durch

if (someExternalValue) {
    while (true) {
        // do something
    }
}

"obwohl das nicht sein darf!" - doch, darf es, und der Compiler hat richtig gehandelt, weil someExternalVariable als volatile deklariert worden sein müsste.

Kann es dann sein das ein Thread diese Variable überschreibt und DANACH ein Thread den neuen wert lesen will, aber trotzdem den alten bekommt weil es nicht volatile ist ??

Ja. Mit volatile kannst du eine definierte happens-before-Relation sicherstellen. Das geht natürlich auch mit diversen anderen Konstrukten (synchronized uvm.).

Wenn du nichts dergleichen verwendest, gibt es keine Garantie dass ein anderer Thread überhaupt jemals den neuen Wert sieht - es kann sein, muss aber eben nicht.

(Ich gehe hier mal von Java aus, das dieses Schlüsselwort überhaupt eingeführt hat - gibt's analog auch z.B. in C#.)