Pre-VKrit: Parallel Programming in Java

Ein Mitarbeiter der AG Kastens hat mich heute von meinem angestammten Arbeitsplatz (F1-Freifläche) verjagt. So richtig begeistert war ich nicht davon. Aber es ist das Zeichen, dass die Vorlesung "Parallel Programming in Java" gestartet ist ("Funktionale Programmierung" ist ja leider doch abgesagt worden).

Vor knapp einem halben Jahr hab ich in einer kleinen Artikelserie geschildert, warum ich von der Behandlung von paralleler Programmierung in "Grundlagen der Programmierung 2"(GP2) nicht richtig begeistert gewesen bin. Programme, mit denen Studenten parallele Programmierung beigebracht werden soll, sollten zumindest thread-safe sein und möglichst den empfohlenen Wegen entsprechen. Zum Beispiel wurde java.util.concurrent komplett ignoriert. Diese Artikel sind aber leider bei dem Server-Crash verloren gegangen.

Aber der "Rauswurf" hat mich auf die Idee gebracht Kastens-Material mal anzusehen. Ich nenne es mal "Pre-VKrit", aber im Grunde ist es nur ein Durchsehen der Vorlesungsfolien. Aufgefallen ist mir folgendes:

• Es geht mit bei dem bekannten DigiClock-Beispiel los, dass in GP2 daneben gegangen ist. Hier wurde aber die running-Variable als "volatile" deklariert. Damit ist das Programm dann auch thread-sicher. Es gibt immer noch Varianten, die für den Zweck einen Block in bestimmten Zeitintervallen auszuführen, die vielleicht besser sind (z.B. ScheduledThreadPoolExecutor), aber immerhin ist es thread-sicher es auf diese Weise zu machen.
• Auf Folie 25 wird java.util.concurrent vorgestellt und das locks-Unterpackage näher besprochen. Insbesondere wird fett markiert, dass die dort zu findenden Lock-Implementierungen die gleichen Speichersemantik haben wie die normale Synchronisation. Leider wird die Semantik des Speichermodells im Rest der Vorlesung mit keinem Wort erwähnt. Keine Ahnung, wieso man fett hervorhebt, dass zwei Konstrukte, die gleiche Speichersemantik haben, wenn man diese Speichersemantik nicht vorstellt.
• Die InterruptedException wird immer noch durchgängig sinnlos verwendet (catch (InterruptedException e) {}). Brian Goetz sagt in "Java Concurrency in Pratice", dass man mit einer InterrupedException vieles machen kann, aber man sollte sie niemals fangen und nur ignorieren.

Aber ansonsten fand ich die Folien jetzt recht gut. Ich würde sie hören, wenn nicht mein Softwaretechnikteil schon lange "voll" wäre. Die Vorlesung relativ stark ausgerichtet auf Datenparallelismus, wie sie im High-Performance-Computing wichtig ist, (Loop Transformation, etc) und weniger auf andere Muster wie parallele Programme strukturiert werden könnten (Active Object, Reactor, Fork-Join, etc.). Eine eher "Doug Lea"-orienterte Vorlesung hätte ich es spannender gefunden, aber auf Grund des PC^2 "in der Nähe" ist es wohl auch eine nachvollziehbare Schwerpunktsetzung.

Wer sich für das Thema interessiert und einen vielleicht etwas anderen Blickwinkel wünscht, sollte sich "Doug Lea: Concurrent Programming in Java" und "Java Concurrency in Practice" von Brian Goetz, Doug Lea, Josh Bloch und anderen aus der Bibliothek besorgen. Doug Leas Buch ist ist älter (2000, insbesondere pre-1.5), sehr muster-orientiert (aber kein Muster-Buch wie POSA2) und wirklich gut. Brian Goetz fügt insbesondere eine ausführliche Behandlung des "neuen" Java 1.5-Speichermodells hinzu und bespricht unter starker Berücksichtigung des java.util.concurrent-Paketes wie moderne, parallele Java-Programme strukturiert werden könnten. Das "JCiP"-Buch fand ich einfacher zu lesen.