Nachdem ich gestern Morgen – direkt nach der Keynote – meine erste Session auf der VSone in München gehalten habe, war ich gestern am späten Nachmittag mit einer weiteren Session an der Reihe. Unter dem Titel

Singleton? Aber threadsicher!

verbarg sich augenscheinlich lediglich die Frage, wie das Entwurfsmuster Singleton threadsicher umgesetzt wird – doch der Teufel steckt bei dieser Frage im Detail.

Nachdem ich vor 11 Teilnehmern zunächst in knappen Worten die Frage erläutert habe, warum die klassische Implementierung nicht threadsicher ist, habe ich einige verbreitete threadsichere oder vermeintlich threadsichere Varianten vorgestellt.

Was als scheinbar leichte Aufgabe begann, endete letztlich in der Analyse des vom C#-Compiler erzeugten MSIL-Codes, der Diskussion über eine Aspekte der Spezifikation von C# und der Erklärung einiger Spitzfindigkeiten innerhalb der .NET-Runtime.

Im Wesentlichen habe ich in der Session dabei die folgenden Punkte behandelt:

• Singleton – klassisch
• Singleton threadsicher – mit Locking
• Singleton threadsicher – Double-checked locking idiom
• Singleton threadsicher – ohne Locking
• Verhalten von statischen Konstruktoren
• Felder vs Eigenschaften

Besonders gefreut hat mich, dass ich mit einer ebensolchen Spitzfindigkeit innerhalb der Runtime von .NET ein nicht reproduzierbares, sporadisch auftretendes Problem im Code eines Teilnehmers lösen konnte.

Das erste Feedback zeigt mir, dass die Session auch den anderen Teilnehmern sehr gut gefallen hat – was mehr kann man sich wünschen?