Podcast: SoftwareArchitekTOUR
(English summary: I'm doing a German podcast on software architecture together with some well-known folks.)
Die mehr oder weniger interessanten Erfahrungen und Meinungen von Michael Stal, Markus Völter, Christian Weyer und meiner Wenigkeit sind seit Neuestem gemeinsam in Audioform konsumierbar, und zwar im Heise Developer-Podcast "SoftwareArchitekTOUR". Episode 0 (alle) ist eine allgemeine Vorstellung, bei Episode 1 (Stal, Völter) wird das Konzept von Entwurfsmustern vorgestellt. In Episode 2 (Tilkov, Völter) geht's um Patterns in Java, in Episode 3 (Stal, Weyer) um Patterns im .NET-Umfeld.
Die ganze Angelegenheit macht wirklich Spaß - zumindest uns Machern :-) Die nächsten paar Folgen sind schon produziert und folgen bald, Kommentare und Ideen für weitere Episoden sind sehr willkommen.
Einen iTunes-Link gibt's natürlich auch.
Das ist euch aber mit Double Checked Locking ein kleiner Fehler unterlaufen im Java Podcast :-) In Java funktioniert DCL i.d.R. nicht da es keine garantierten Memory Barriers gibt (Ab Java5 geht es mit der geänderten volatile spec). Im Podcast klang es aber so als würde es ein wertvolles Idiom für die Programmierung in Java sein. Ist aber eigentlich eins was man verbieten sollte da es einfach nicht funktioniert (bzw. abhängig von der JVM dem Compiler und Optimizer).
Sehr gut! Haben auch schon zwei andere gemerkt. Nicht, dass ich das etwa gewusst hätte, aber ich habe mich ja auch nicht aus dem Fenster gelehnt ;-)
Werden wir in einer der nächsten Episoden korrigieren.
Habe mal etwas gegoogled und die Seite gefunden http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Sie erklärt das Problem kurz und knapp und warum es eigentlich kein Java Problem ist sondern eher ein generelles. Das Pattern ist ursprünglich mal in C++ entstanden wo durch gezielte Memory Barriers das ganze auch funktioniert :-)
Die meisten vergessen das ein x = new B() eigentlich ein ALLOC B, INIT B, ASSIGN x=B ist und es nach optimierung auch ALLOC B, ASSIGN x=B, INIT B sein darf was dann das DCL kaputt macht wenn der Thread switch zwischen ASSING x=B und INIT B ist (zweiter Thread bekommt die Instanz nicht initialisiert und wird höchst wahrscheinleich eine Exception auslösen). Schlimmer ist noch das der INIT part auch noch inlined werden kann womit eine ganze Menge von Anweisungen das Problem verursachen kann.