volatile & Thread#sleep/yield - Versteh ich nich

[hdi]

Hi,
ich hab das mal im Buch "Killer Game Programming" gelesen und jetzt bin ich grad wieder in der JLS drübergestolpert. Bitte lest euch mal den kurzen Abschnitt über Thread#sleep/yield durch:

Threads and Locks

Bitte beachtet auch das Code-Bsp darunter!

Meine Frage ist jetzt: Ich hab noch nie nen volatile genutzt und hab oft die lifetime-booleans von thread-schleifen über einen anderen Thread auf false gesetzt - es hat aber immer funktioniert! War das nur Glück?
Außerdem: Was hat das jetzt eigentlich mit Thread#sleep/yield zu tun? Wenn ich statt der sleep-Anweisung in der while-Schleife zB nur ein sysout habe, hab ich dann das Problem nicht mehr dass der Thread evtl. ne veraltete Version der Variable aus dem Cache liest?

So wie sich das anhört muss man jeden primitive auf volatile setzen sobald mehr als 1 Thread den benutzen. Ich frag mich warum dass genau an dieser Stelle in der JLS erwähnt wird...

edit: Oder ist das irgendwie so ne theoretische "Halbwahrheit"? Mir fällt dazu grad auch das hier ein:

public static void main(String[] x){
  new JFrame().setVisible(true);
}

Ich glaub laut JLS sollte das auch immer auf dem EDT ausgeführt werden. In der Praxis ist es aber glaube ich noch nie einem Menschen gelungen dieses Programm auszuführen ohne dass ein Frame erscheint??!

Thx

 

[Ebenius]

Sobald Du zeitgleich unsynchronisiert auf Felder zugreifst die nicht volatil sind (egal welcher Typ), gehst Du das Risiko ein, auf einer lokalen Kopie zu arbeiten. Sicher gibt es hier deutliche Unterschiede in verschiedenen Maschinenimplementationen und auf verschiedener Hardware.

Ganz einfach: Immer synchronisieren oder volatil setzen, nie raten. :-D

Ebenius

 

[hdi]

Ich wiederhole:

Primitive = volatile setzen (da synchen ja nicht geht für Primitive)
Objekte = synchen, oder volatile setzen (Oder anders gefragt: volatile = synchronized an jeder Stelle im Programm?)

Danke

edit: Aber trotzdem nochmal ne Frage: Wieso wird das gerade bei sleep/yield in der JLS erwähnt? Hat doch damit nix zu tun?

 

[Ebenius]

Huh?

 

[hdi]

Naja, also Primitive auf volatile setzen wenn 2+ Threads darauf zugreifen, denn synchronisieren kann man ja auch Primitive nicht, die haben ja keinen Monitor??

Und bei Objekt-Variablen entweder ein synchronized drum, oder halt die Variable auch auf volatile setzen. Und hier frage ich ob ein volatile auf einer Objekt-Variable gleichzusetzen ist mit einem synchronized-Block an jeder Stelle im Code um diese Variable?

 

[Ebenius]

Was ich damit sagen wollte: Du musst gegen einen Monitor synchronisieren. Das muss doch nicht das Feld sein auf das Du synchron zugreifst:

public class A {
  private boolean b;
  private final Object monitor = new Object();

  public void setB(boolean b) {
    synchronized(monitor) {
      this.b = b;
    }
  }

  public boolean getB() {
    synchronized(monitor) {
      return b;
    }
  }
}

Wenn der Zugriff immer über set und get geht, ist alles save...

Ebenius

 

[hdi]

Ja ok, aber wenn ich mir nicht diesen Umstand machen will muss ich Primitive auf volatile setzen. Oder ist es irgendwie eleganter mir für dafür Pseudo-Objekte zu erstellen?

Als dritte Möglichkeit würde doch auch folgendes gehen:

public synchronized void kill(){
  running = false;
}

@Override
public synchronized void run(){
 while(running){
       ...
 }
}


// anderer Thread:
myObject.kill();

Oder?

 

[Ebenius]

Auf jeden Fall ist das eleganter. Was -- meiner Meinung nach -- noch besser ist, ist, den Monitor zu verstecken. Das erspart einem eine Menge potentieller Deadlock-Probleme, wenn jemand anderes mit Deinen Objekten arbeitet, weil eben niemand auf den selben Monitor synchronisieren kann. Das ist manchmal erwünscht und manchmal eben nicht. Wenn es nicht ausdrücklich einen Nutzen gibt, wenn ein anderer gegen meine Objekte synchronisieren kann, dann kennt er den Monitor auch nicht:

public void kill(){
  synchronized(myPrivateMoni) {
    running = false;
  }
}

@Override
public void run(){
 synchronized(myPrivateMoni) {
  while(running){
         ...
  }
 }
}

Volatile sollte man IMHO dort verwenden, wo sich der Wortsinn aufdrängt. Volatil ist etwas das sich häufig ändert. Eine Variable [c]running[/c] sollte in den meisten Anwendungsfällen dieser Wortbedeutung nicht standhalten.

Ebenius

 

[hdi]

Understood. Thx

 

[ThreadPool]

Volatile sollte man IMHO dort verwenden, wo sich der Wortsinn aufdrängt. Volatil ist etwas das sich häufig ändert. Eine Variable [c]running[/c] sollte in den meisten Anwendungsfällen dieser Wortbedeutung nicht standhalten.

Ich finde das Beispiel suboptimal. IMHO wird volatile am häufigsten für solche Statusflag-Geschichten verwendet. Die Interpretation der Übersetzung ist etwas anders zu verstehen. Ich bin der Meinung das "volatile" (flüchtig, unberechenbar) dafür steht das dem Compiler mitgeteilt wird das sich die Variable zwischen Lesezugriffen ändern kann und deshalb bei jedem Zugriff immer neu geladen werden muss.

private volatile boolean cancelled;

public void kill(){
  cancelled = true;
}
 
@Override
public void run(){
  while(!cancelled){
      synchronized(lock) {
          //atomar auszuführender Code
      }
  }
 }
}

 

[Ebenius]

Hm. Seltsamer Weise habe ich auf den Sun-Seiten kein passendes Best-Practice-Paper dazu gefunden. Für mich wären die Standardfälle für volatile [c]modCount[/c] in einer Collection oder [c]numBytesFlushed[/c] in einem Stück I/O. Ein boolean der anzeigt ob ein Worker noch lebt; der nur ein einziges mal geändert wird (kill klingt zumindest so ) wäre bei mir eher nicht volatil. Vielleicht Geschmackssache? Oder vielleicht liege ich da einfach falsch? Ein guter Artikel dazu wäre gar nicht schlecht, wer hat was?

Ebenius

 

[eRaaaa]

wer hat was?

AngelikaLanger.com - Details zu volatile-Variablen - Angelika Langer Training/Consulting

+

AngelikaLanger.com - Regeln für die Verwendung von volatile - Angelika Langer Training/Consulting

 

[Ebenius]

Schon der Bookmark-Sammlung hinzugefügt. Allerbesten Dank. Mich wundert trotzdem, dass ich da von Sun nix gevon. Sonst mag ich die Dokumentenbasis dort sehr.

Ebenius

 

[hdi]

Danke für die Links, ich werd mir das auch mal anschauen.

@ThreadPool
In deinem Bsp ist das synchronized doch unnötig?! Hat doch mit dem

cancelled

nix zu tun.

 

[ThreadPool]

Danke für die Links, ich werd mir das auch mal anschauen.

@ThreadPool
In deinem Bsp ist das synchronized doch unnötig?! Hat doch mit dem

cancelled

nix zu tun.

Im obigen Stück Code, ja. Das synchronized ist noch drinnen, da ich (im Original) in der run-Methode eine Datenstruktur innerhalb der Klasse verändert habe die auch als Kopie von aussen mit einem getter angefragt werden kann.