Diskussion:Doppelt überprüfte Sperrung

Anti-Pattern

Wenn das ein Anti-Pattern ist, wie geht es denn dann richtig?
Es werden nur Negativ-Beispiele genannt. Ein Beispiel, wie man es statt dessen machen sollte, wäre schön. --217.91.238.66 12:06, 5. Jun. 2013 (CEST)

Double-Checked Locking kann durchaus verwendet werden, wenn man weiß, was man in der jeweiligen Programmiersprache zu beachten hat.

Die generell korrekte Lösung ist, dass ausschließlich synchronisiert auf das Feld zugegriffen wird, z. B. durch die Synchronisierung der kompletten Methode:

public class Foo
{
    private Helper helper = null; 
 
    public synchronized Helper getHelper() // Komplette Methode synchronisieren
    {
        if(helper == null)
            helper = new Helper();

        return helper; 
    }
 
    // ...
}

--YotMuPi (Diskussion) 00:30, 10. Dez. 2013 (CET)

---

Die Behauptung im Artikel, doppelt überprüfte Sperrung wäre ein Anti-Pattern, ist ebendas: eine reine Behauptung ohne Nachweis oder auch nur Begründung. Es wird nicht einmal die Intention dargestellt, sondern einfach kolportiert, es würde häufig von unerfahrenen Programmierern benutzt. Der Verweis auf den Locking-Artikel ist dabei auch überhaupt nicht hilfreif, weil der auf das Problem, das man mit doppelt überprüftem Sperren umgehen will, gar nicht eingeht.

Tatsächlich ist doppelt überprüfte Sperrung an sich weder Pattern noch Anti-Pattern, sondern ein Idiom, obwohl richtig ist, dass es von manchen als Anti-Pattern betrachtet wird. Dann können wir aber auch gleich Singleton als Anti-Pattern ausschreiben, das wird schließlich noch viel öfter falsch oder inflationär benutzt. 82.198.213.168 13:49, 25. Apr. 2014 (CEST)

Ich habe das mal überarbeitet und der Text sollte jetzt stimmen. Die Codebeispiele zeigen jedenfalls auch die korrekte Version. — MovGP0 21:57, 27. Jul. 2014 (CEST)

Um nochmal auf das Pattern/Anti-Pattern zu kommen: Singleton wird in der Tat von vielen (den meisten?) Entwicklern als Anit-Pattern angesehen. DCL wird oft als Anti-Pattern angesehen (was schließt ein Idiom davon aus ein Anti-Pattern zu sein?) es ist mir aber keine Referenz bekannt, die über Zahllose Diskussionen im Internet und Blogs hinaus geht. Xycolon (Diskussion) 11:22, 4. Jan. 2018 (CET)

Ein Anti-Pattern war es vor allem vor Java 1.5! In den meisten anderen Programmiersprachen, die Memory-Fences vor und nach jedem Lock-Block einsetzen (oder volatile richtig verwenden) und nicht Teil-Initialisierte oder Verzögert-Initialisierte Variablen-Zeiger herausgeben, war es noch nie ein Problem. Daher hat die Legende der Anti-Pattern einen starken Bezug zu Java, ist aber bei weitem nicht allgemeingültig.

C# Beispiel ist nicht korrekt.

Es wird kein volatile gebraucht, das Schlüsselwort lock erzeugt bei Eintritt einen Full-Fence und bei verlassen ebenfalls einen. (nicht signierter Beitrag von 85.178.64.52 (Diskussion) 00:52, 29. Jan. 2018 (CET))

--Benutzer:Anonym 16:08, 1!. Sept. 2021 (CET)

Eben, ein Fence kostet weniger als eine atomare Speicheroperation zum Locken und Ent-Locken (ohne, dass parallel ein anderer Thread das selbe versucht, sonst geht's in den Kernel). (nicht signierter Beitrag von 176.198.137.192 (Diskussion) 16:09, 11. Sep. 2021 (CEST))

Bessere Beispiele

Eine hälfte der Beispiele behandeln wie man das Muster zur initialisierung von Variablen verwendet, die andere hälfte wie diese fälle besser gelöst werden können (statische Variablen). Das erweckt den eindruck dass dieses muster immer ersetzt werden kann/soll. Ich schlage ein Beispiel vor wie mit diesem Musters geprüft wird ob ein Container leer ist und ansonsten ein Element des Containers zurückgegeben wird. Proeo (Diskussion) 13:12, 7. Okt. 2022 (CEST)