Früher gab es InterlockedCompareExchange bzw. InterlockedCompareExchangePtr,
das kapselte Delphi dann mal als TInterlocked,
aber man darf auch gern das neuere multi-platforme AtomicCmpExchange der System-Unit verwenden, mit bissl compilermagic bei der Typenbehandlung

Jo, schauen ob leer,
wenn ja, dann erstellen,
die Referenz threadsicher eintragen/austauschen, was mit einer atomaren Operation am Einfachsten geht (Interlocked, Atomic oder LOCK im Assembler)
und wenn nicht erfolgreich, dann die Instanz wieder freigeben. (falls ein anderer Thread das gleichzeitig gemacht hatte und schneller war)

markieren

Delphi-Quellcode:

if not Assigned(XXX) then begin
  NEW := TIrgendwas.Create;
  if AtomicCmpExchange(XXX, NEW, nil) <> nil then
    NEW.Free;
end;
XXX.DoSomething;

Ja genau, für das eigentliche Erzeugen der Instanz gibt es diese Methoden.
Was ich meine ist aber, das die erzeugte Klasse im Singleton auch ThreadSicher sein muss.
Je nachdem hat diese ja noch globale Felder zu verwalten.
TSingleton<TKlasse>

Um diese abzusichern könnte man doch das globale CS des TSingletons wieder-verwenden,
und an die erzeugte Instanz im Create der TKlasse übergeben.
Macht das Sinn, oder sollte TSingleton und TKlasse jeweils ihr eigenes CS haben und verwalten ?

Ich weiss das man generell besser die Klassen trennen sollte,
Aber in diesem Fall macht TKlasse ja nur im TSingleton Sinn.
Also könnten hier Ressorcen optimiert werden, weil TKlasse nie allein verwendet wird.

Zitat von Rollo62:

Um diese abzusichern könnte man doch das globale CS des TSingletons wieder-verwenden,
und an die erzeugte Instanz im Create der TKlasse übergeben.

Warum, wo siehst du hiervon den Mehrwert?
Ob ich ein ode zwei Mutexe, Kritische Abschnitte oder Monitore benutze ist doch nun wirklich zu vernachlässigen.

Der Mehrwert wäre das die TKlasse eine CS per DI übergeben bekäme, und sich nicht selber drum kümmern muss.
Allerdings ist TKlasse ja selber ein Singleton, insofern hast du Recht.
Deshalb frage ich mich was hier wohl der bessere Weg wäre.