Veranstaltungen

Spring Boot (Michael Simons)

Do, 25. Januar 2018

Kalender als XML und iCal

Wir unterstützen...

Elterninitiative Kinderkrebsklinik e.V

Kinderkrebsklinik e.V

Sponsoren

Wir danken unseren Sponsoren:

Permanente Sponsoren

Uni Düsseldorf
(Raum und Beamer)


(Preise)


(Preise)


(Preise)


(Preise)

Mitgliedschaften



java.net Member

Events

Nachlese Java Memory-Model | Print |
Written by Harald Menke   
Wednesday, 11 March 2009 11:38
Video: Leider konnten wir diesen Vortrag nicht filmen. Allerdings ist ein ähnlicher Vortrag von Angeliker Langer bereits im Netz.

Update: Folien zum Vortrag

Frau Angelika Langer, Java-Trainer und IT-Consultant (http://www.angelikalanger.com), zeigte am heutigen Abend an, dass die threadsichere Programmierung zu den Grundlagen der Softwareentwicklung gehört, und das insbesondere in einer Welt, in der die Anzahl der Cores pro Prozessor, und dieser Systeme insgesamt, zunimmt. War es schon bei den Singlecore-Systemen wichtig, um die Resourcen konkurrierende Prozesse auf ihren jeweiligen Kontext zu beschränken, gilt das um so mehr bei echter Synchronität.

Bei den Prozessoren findet das seinen Niederschlag in hardware-unterstützten Kontextwecheln, den entsprechenden Registern und Flags, bis hin zu den die VMs unterstützenden Features, auf welche diese zurückgreifen können um somit den Durchsatz zu steigern. Die JVM ist eine davon und setzt auf diese in den Prozessoren integrierte Funktionalität auf.

Der Vortrag, dessen Thema lautete "Das Java Memory Model", beleuchtete die Aspekte der um gemeinsame Speicherresourcen (Mainmemory, Cache, Register) konkurrierenden Threads, Tasks, Producer und Consumer. Die Programmiersprache Java bietet die dafür entsprechenden Methoden an. Mit dem Erscheinen von Java 1.5 wurde der "Methodendschungel" erweitert um die Utility-Methoden der enumerated constants der "TimeUnit" Klasse (zum "Schlafenlegen" eines Threads), dem Executor-Interface des "java.util.concurrent" Package zum Ausführen von "Runnable" Objekten, das Lock-Objekt und die entsprechenden Methoden (java.util.concurrent.locks). (Die "try/finally" Abschnitte sind hier mit Vorsicht zu genießen, denn Deadlocks sind zu vermeiden: Gelockte Objekte müssen ja wieder freigegeben werden! Nicht, das beispielsweise zwei Threads auf die jeweils zeitgleich gelockte Resource des jeweils anderen Threads warten müssen, dann "hängt" das Programm.), die Definition eines Condition Objekts der Klasse "java.util.concurrent.locks" mit den Methoden "await()" und "signalAll()" als Alternative zu "wait()" und "notifyall()".

Das "java.util.concurrent.atomic" Package bietet atomare Operations ohne Locking (da atomar, nicht erforderlich) und findet Anwendung bei den primitiven Datentypen, Long und Double ausgenommen. Die JVM verarbeitet 32-Bit Worte und damit scheiden Long und Double aus.

public class Beispiel {
  int zahlA =  0;
  public synchronized int zahlA() {return zahlA++;}
  //gibt 1 zurück

  AtomicInteger zahlB = new AtomicInteger(2);
  public int zahlB() {return zahlB.getAndIncrement();}
  //gibt 3 zurück

  AtomicInteger zahlC = new AtomicInteger(0);
  public int zahlC() {
    int returnvalue;
    do {
      returnvalue = zahlC.get();
    }
    while (!zahlC.compareAndSet(returnvalue, returnvalue+1));
    return returnvalue;
  }
  //gibt 1 zurück und, falls eine Unterbrechung stattfindet, wird der Loop eben solange
  //wiederholt, bis es geklappt hat. Der Vergleich liefert "false", wenn returnvalue eine
  //Null-Referenz ist.	
}

Diese Methoden in Verbindung mit einer atomar deklarierten Variablen bedürfen keiner Synchronisation. Zwar kann der Thread der letzten Methode unterbrochen werden, doch beeinflußt das nicht den zurückgebenen Wert.

Volatile ist einer synchronisierten Methode "im Kleinen" ähnlich. Die Deklaration "volatile" legt fest, dass der Wert einer Variablen immer "refreshed" (aus dem Memory gelesen) und "flushed" (wieder ins Memory geschrieben) werden muss, und der Wert somit nicht von einem Thread gecached oder in ein Register geschrieben wird.

Grundsätzlich gilt jedoch, für längere oder umfangreiche Befehlssequenzen, die thread-sicher ausgeführt werden müssen, sind die Methoden als "synchronized" zu deklarieren.

Abschließend: Der Besucherandrang war sehr groß, Herr Fabian Fritz vermerkte dies erfreut zu Beginn, und die Akustik im Hörsaal war auch ohne Mikrofon ausgezeichnet. Der Vortrag von Frau Angelika Langer war, so ich es denn zu beurteilen vermag, in seinem fachlichen Informationsgehalt enorm "dicht" und sehr souverän in der Präsentation.

Harald Menke