Multithreading and volatile

[Empire Phoenix]

Nun eigentliche eine einfache Frage, wenn ich (performancetechnisch mal ignoriert) 'einfach' jede benutzte referenz (Variable) mit volatile kennzeichne müsste ich dann sämtlichen Multithread synchronizations problemen entgehen? (Abgesehen vom DeadLock)

 

[SlaterB]

The volatile keyword in Java

hab noch nix dazu ausprobiert, aber anscheinend wird dort
- nur jeder Aufruf einzeln synchronisiert, das reicht nicht immer, z.B. verhindert man damit nicht ConcurrentModificationExceptions beim Iterator-Durchlauf einer Liste,
siehe auch
http://www.java-forum.org/allgemeine-java-themen/95450-code-synchronizen.html
weiter unten

- es liest sich so, als wird nur die Referenz einzeln synchronisiert nicht das dahinterstehende Objekt,
wenn nun zwei Threads gleichzeitig auf jeweils ihre Variable zugreifen?..
müsste man testen
(*)

> (Abgesehen vom DeadLock)

gerade Deadlock ist nicht möglich, siehe ersten Link, was die Möglichkeiten wohl schon prinzipiell begrenzt


edit:
(*)
aha, es wird nichtmal für die Dauer einer Methode synchronisiert sondern nur für den Zugriff auf die Variable,
damit schafft man natürlich sehr wenig

 

[ice-breaker]

JAX TV: Java-Programmierung im Multicore-Zeitalter

wenn ich mich recht entsinne, erzählt Frau Langner einiges über das Memory Modell, volatile und synchronized-Blöcke, ein wirklich sehr sehr interessanter Vortrag.

 

[FArt]

Nun eigentliche eine einfache Frage, wenn ich (performancetechnisch mal ignoriert) 'einfach' jede benutzte referenz (Variable) mit volatile kennzeichne müsste ich dann sämtlichen Multithread synchronizations problemen entgehen? (Abgesehen vom DeadLock)

Nein, denn volatile funktioniert nur auf atomare Aktionen wie z.B. dem setzen/lesen eines Wertes. Das gilt sogar für long oder double, die ja eigentlich nicht atomar geschrieben werden könnten, aber so behandelt werden. Ein Deadlock kann nie eintreten.

Threads and Locks

 

[ice-breaker]

@FArt: Dein Dokument ist von 2000 also noch J2SE 1.3, ich würde da keine Hand für ins Feuer legen, dass noch irgendeine der Aussagen gilt

Zudem erinnere ich mich, dass Frau Langner in ihrer Session erzählt hat, dass Java mit Version 5 ein ganz neues Memory-Modell bekommen hat, als Anmerkung weil es in deinem verlinkten Beitrag scheinbar auch angerissen wird.

 

[FArt]

Anderer Link, die Aussage hat aber Bestand.

Ist nur schwerer zu lesen.. man muss sich mal mit "happens-before orders" und "well formed executions" auseinandersetzen, aber hier steht jetzt alles drin: JSR-000133 Java Memory Model and Thread Specification Revision - Final Release

 

[Gelöschtes Mitglied 6946]

Soweit wie ich das verstanden habe, sorgt das volatile einmal dafür, dass double und long atomar geschrieben und gelesen werden und zum anderen, dass der Wert der damit gekennzeichneten Variablen für einen Thread immer den Wert hat, der zuletzt geschrieben wurde, egal durch wen. Fehlt das volatile, so kann es dazu kommen, dass die VM eine Optimierung durchführt und zwei Threads nicht wirklich die selbe Variable sehen - obwohl ein Thread vorher darauf geschrieben hat, ist die Änderung für einen anderen Thread nicht zu sehen.

Ein Beispiel (frei nach "Effective Java", empfehlenswertes Buch): ein boolean-Flag bestimmt, ob eine Schleife laufen soll

while (shouldRun) {
  doSomething();
}

// koennte optimiert werden zu

if (shouldRun) {
  while (true) {
    doSomething();
  }
}

Soweit mich mein Gedächtnis nicht trügt, hab das Buch grad nicht hier. Mit volatile verhindert man sowas. Ist aber kein Ersatz für Synchronisation, wenn es um Objekte oder sowat geht.

 

[Empire Phoenix]

dein beispiel ist das was der compiler dann daraus amcht evtl oder? Weil sonst gibt es nur begrezten sinn

 

[ice-breaker]

Soweit wie ich das verstanden habe, sorgt das volatile einmal dafür, dass double und long atomar geschrieben und gelesen werden und zum anderen, dass der Wert der damit gekennzeichneten Variablen für einen Thread immer den Wert hat, der zuletzt geschrieben wurde, egal durch wen.

jup, der Vorteil ist einfach das man es so bauen kann, dass das Lesen unsynchronisiert korrekt funktioniert und man nur noch für das Schreiben eben synchronisieren muss, kann sich an einigen Stellen lohnen:

class Foobar
private volatile int num;

public int getNum() {
  return num;
}

public synchronized void setNum(int num) {
  num = num;
}
}

(ist natürlich ein absolut dämliches Beispiel, geht nur darum, dass man nur noch das Schreiben synchronisieren muss)

Fehlt das volatile, so kann es dazu kommen, dass die VM eine Optimierung durchführt und zwei Threads nicht wirklich die selbe Variable sehen - obwohl ein Thread vorher darauf geschrieben hat, ist die Änderung für einen anderen Thread nicht zu sehen.

Das und auf Rechnern mit mehreren Cores oder Prozessoren können die Variablen im Cache eines Cores/Prozessors hängen, womit man auf solchen Rechnern diese Probleme viel eher haben wird als auf einem SingleCore-Rechner.

Soweit mich mein Gedächtnis nicht trügt, hab das Buch grad nicht hier. Mit volatile verhindert man sowas. Ist aber kein Ersatz für Synchronisation, wenn es um Objekte oder sowat geht.

jup, volatile sagt eben, dass die Information immer aus dem Hauptspeicher geladen werden soll und nicht aus dem Cache. Ist dadurch natürlich aber langsamer, wenn man sich aber dadurch an manchen Stellen Synchronisierungen sparen kann, sehr von Vorteil.

dein beispiel ist das was der compiler dann daraus amcht evtl oder? Weil sonst gibt es nur begrezten sinn

ja ist es

 

[ThreadPool]

jup, der Vorteil ist einfach das man es so bauen kann, dass das Lesen unsynchronisiert korrekt funktioniert und man nur noch für das Schreiben eben synchronisieren muss, [...]

jup, volatile sagt eben, dass die Information immer aus dem Hauptspeicher geladen werden soll und nicht aus dem Cache.

Du widersprichst dir da selbst. Das Schreiben auf eine als volatile deklarierte Variable muss nicht
synchronisiert werden.

Ein Beispiel findet sich unter 8.3.1.4 volatile Fields der JLS The Java Language Specification, Third Edition - TOC

 

[ice-breaker]

ja es war ziemlich doof ausgedrückt, per Language-Spec muss es natürlich nicht

Ich bezog mich dabei auf ein erfundenes Beispiel bei dem man zur Synchronisierung das Lesen und Schreiben synchronisiert hätte, mit volatile könnten wir uns das Synchronisieren beim Lesen sparen, da wir ja immer den aktuellsten Wert haben.
Ich ging dadevon aus, dass die Anwendung auf Grund irgendwelcher höheren Logik beim Lesen trotzdem locken muss, weil was weiß ich
Mir fällt gerade kein Beispiel ein, hatte es aber schon, dass ich so nur noch das Schreiben synchronisieren musste, damit mehrere Threads sich beim Schreiben nicht die Daten gegenseitig in einen inkonsistenten Zustand bringen, das Lesen ging dann schön ohne Locks.

Natürlich muss es per volatile Spec nicht.