Diskussion:Liste von Singleton-Implementierungen

message: Ich finde die C# Implementierungen nicht gerade schön, verwendet man nicht eher ein Getter als ein Funktion (getInstance())?
IceOnly 00:43, 15.05.2011 (CEST)
Ich habe die Variante 2 des C#-Beispiels aus dem Artikel entfernt (), da sie (denke ich) fehlerhaft ist.
Grund ist, dass beim Lesen des Wertes eine memory barrier fehlt.
Wenn man jetzt einen Thread hat, der nach instance schreibt:
* 1. Daten des neu erzeugeten Objekts in den Speicher schreiben
* 2. Eine MemoryBarrier
* 3. Die Referenz nach instance schreiben
und einen, der instance ausliest:
* A. Referenz aus instance auslesen
* B. Daten des Objekts lesen
dann darf die Runtime dies folgendermaßen anordnen:
* B.
* 1.
* 2.
* 3.
* A.
so dass beim Schritt B nicht-initialisierte Daten (bzw. Nullen) gelesen werden.
B darf hierbei über 2 verschoben werden, weil es in einem anderen Thread ist (und die Barrier nur für einen Thread gilt).
B kann (zumindest aus globaler Sicht) vor A ausgeführt werden wenn z.B. ein Objekt, das im Speicher direkt neben dem Singleton liegt, gelesen wird und dadurch die Daten schon in den Prozessorcache gelesen werden.
88.67.88.127 20:34, 25. Feb. 2008 (CET)
replies: text: Ich habe die C#-Beispiele überarbeitet und erweitert. Sollte jetzt besser sein. — MovGP0 04:13, 13. Apr. 2013 (CEST)
thread_title:  C# 

message: Das Python Borg Pattern war kaputt(tm) ("inst" wurde nicht returned). Habe das mal gefixt. 84.58.191.156 00:44, 1. Dez. 2006 (CET)
thread_title:  Python 

message: Habe ein paar Dinge verschönert, denn so war der Code nicht mal compilierbar. Finde auch daß ein oder zwei Beispiele reichen, z.B. Java und C++. (nicht signierter Beitrag von 193.16.191.2 (Diskussion) 09:48, 21. Sep. 2010 (CEST)
replies: text: Also mit C++ bin ich nicht vertraut, aber zB. die generischen C#-Beispiele sind nicht gerade trivial, weshalb es nicht schadet ein paar Beispiele mehr zu geben. Es reicht aber sicher ein Beispiel pro Variante. — MovGP0 04:14, 13. Apr. 2013 (CEST)
thread_title:  C++ Code 

message: Die Realisierung mit enum verhindert, dass man das Singleton von einem anderen Objekt außer Object vererben kann.
public enum Singleton extends AnyObject {
  INSTANCE;
}
liefert einen Fehler, da in Enums ein extends nicht möglich ist. Die Realisierung kann man also nur eingeschränkt benutzen. --Florian Hurlbrink (Diskussion) 12:54, 22. Okt. 2010 (CEST)
thread_title:  Zum Abschnitt "Alternative Implementierung mit [[Aufzählungstyp|Enum]] in [[Java (Programmiersprache)|Java]] ab Version 5" 

message: – GiftBot (Diskussion) 02:18, 10. Feb. 2016 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekter Weblink 

message: Die Beschriebene synkronisierung der Klassenmethode wurde gut fatalisiert. Jedoch ist die empfohlene Methode nur im idealfall Lazy da mit reflection ein vorzeitiges laden der klasse und dem entstehen der Instanz ein Nebeneffekt sein. Lazy in dem Fall nicht korrekt sondern eher Dozily. Auch wird das problem nicht behoben weil das laden von Klassen sowieso auf den classloader synkronisiert ist, ebenso wie eine synkronisierte methode. Besser ist
    public final class Singleton{
      private static Singleton INSTANCE = null;
      public static Singleton getInstance() {
        if (INSTANCE != null){
          return INSTANCE;
        }
        synchronized(Singleton.class) {
          if(INSTANCE != null){
            return INSTANCE;
          }
          return INSTANCE==new Singleton();
        }
      }
      private Singleton(){}
    }
Das ist Lazy im Sinne des spätesten instanziierung. (nicht signierter Beitrag von 92.230.142.220 (Diskussion) 08:39, 21. Aug. 2016 (CEST)
replies: text: Der Einwand mit dem frühen Laden per Reflection ist durchaus berechtigt und sollte im Text erwähnt werden. Dein Ansatz mit Double-Checked-Locking wird ohne volatile aber nicht sauber funktionieren.--Der Hâkawâti ✉ 16:24, 21. Aug. 2016 (CEST)
thread_title:  Lazy java singletons