ECMA - 335 topic 12.6.8
Kategorie Allgemein .Net
It is explicitly not a requirement that a conforming implementation of the CLI guarantee that all state updates
performed within a constructor be uniformly visible before the constructor completes. CIL generators can
ensure this requirement themselves by inserting appropriate calls to the memory barrier or volatile write
instructions.
Und ??? Was soll das?
It is explicitly not a requirement that a conforming implementation of the CLI guarantee that all state updates
performed within a constructor be uniformly visible before the constructor completes. CIL generators can
ensure this requirement themselves by inserting appropriate calls to the memory barrier or volatile write
instructions.
Und ??? Was soll das?
Also der ECMA - 335 Standard ist die (mindest)
Spezifikation für die Implementierung einer CLI, also der Runtime des .Net-Frameworks.
Im Abschnitt 12.6.8 Memory Issues wird ausgesagt, dass der Status eines Objektes, welcher innerhalb eines Konstruktors bei der Initiierung geändert werden kann, nicht unbedingt vor Beendigung des Konstruktors transparent nach aussen bekannt gemacht werden muß
Und was heißt das?
Der Code im Kasten kann bei einer Implementierung funktionieren, muß aber nicht, denn die Zuweisung des Pointers auf instance könnte theoretisch passieren, bevor der Konstruktor beendet ist.
Dies würde bedeuten, dann ein zweiter Thread beim ersten if auf !=null prüft und somit eine Referenz auf ein nicht instanziertes Objekt zurück gäbe.
Weil man weiß, ja nie, was so ein Compilert mit einem seiner Code macht, wenn er ihn optimiert.
So könnte es sein, dass mittels des Keywords volatile das Problem beseitigt ist, weil der Compiler, dann ja keine Optimierung für das Member instance machen dürfte.
Aber es sollte in .Net ab Framework 2.0 funktionieren
Gruß JJR
Im Abschnitt 12.6.8 Memory Issues wird ausgesagt, dass der Status eines Objektes, welcher innerhalb eines Konstruktors bei der Initiierung geändert werden kann, nicht unbedingt vor Beendigung des Konstruktors transparent nach aussen bekannt gemacht werden muß
Und was heißt das?
| public
sealed
class
Singleton { static Singleton instance=null; static readonly object padlock = new object(); Singleton() { } public static Singleton Instance { get { if (instance==null) { lock (padlock) { if (instance==null) { instance = new Singleton(); } } } return instance; } } } |
Der Code im Kasten kann bei einer Implementierung funktionieren, muß aber nicht, denn die Zuweisung des Pointers auf instance könnte theoretisch passieren, bevor der Konstruktor beendet ist.
Dies würde bedeuten, dann ein zweiter Thread beim ersten if auf !=null prüft und somit eine Referenz auf ein nicht instanziertes Objekt zurück gäbe.
Weil man weiß, ja nie, was so ein Compilert mit einem seiner Code macht, wenn er ihn optimiert.
So könnte es sein, dass mittels des Keywords volatile das Problem beseitigt ist, weil der Compiler, dann ja keine Optimierung für das Member instance machen dürfte.
Aber es sollte in .Net ab Framework 2.0 funktionieren
Gruß JJR
| Permalink | 
