Zitat von r2c2:

Zitat:

Wäre der Konstruktor also nicht geschützt, dann würde es sofort knallen.

Schön wärs. Das fiese ist ja, dass es oft dennoch irgendwie tut und irgendwann zu sehr lustigen Effekten kommt.

Gut vielleicht hätte ich schreiben sollen "könnte" - ich gehe aber immer davon aus, dass es knallt und
gerade das kann ich damit ja verhindern ...

Zitat von r2c2:

Zitat:

Es geht also darum, wie ich Objekte Thread-Safe bekomme - und ich möchte meine Objekte generell Thread-Safe haben und nicht nur unter ganz bestimmten Bedingungen.

Vielleiht hab ich dich auch falsch verstanden. Willst du eine Thread-Safe Thread-Klasse haben (wie dein Code suggeriert) oder willst du andere Objekte Thread-Safe machen (und das aber richtig) oder willst du einfach immer alles Thread-Safe machen?

Was ist der Unterschied? Ein TThread ist auch einfach nur ein Objekt ...
Benutze ich hier aber beispielhaft um das zu erläutern, denn Thread-Safe benötige ich ja nur im Zusammenhang mit Threads.
Aber welches Objekt man auf die skizzierte Art und Weise schützt ist egal.

Zitat von Sir Rufo:

Zitat:

Vielleiht hab ich dich auch falsch verstanden. Willst du eine Thread-Safe Thread-Klasse haben (wie dein Code suggeriert) oder willst du andere Objekte Thread-Safe machen (und das aber richtig) oder willst du einfach immer alles Thread-Safe machen?

Was ist der Unterschied? Ein TThread ist auch einfach nur ein Objekt ...
Benutze ich hier aber beispielhaft um das zu erläutern, denn Thread-Safe benötige ich ja nur im Zusammenhang mit Threads.
Aber welches Objekt man auf die skizzierte Art und Weise schützt ist egal.

So langsam versteh ich, was du meinst. War nur ein bisschen unintuitiv für mich, dass du nen Thread gleichzeitig als Kontext und Beispiel verwendet hast.

Was du hier also beschriebst, ist eine Anwendung des RAII-Idioms zum Verwalten der CS-Instanzen. OK. Bleibt noch das Problem, das himitsu genannt hat, aber dafür hat er ja auch schon ne Lösung gepostet. Das ist soweit OK und auch ein interessanter Ansatz.

Trotzdem fällt mir kein sinnvoller Fall ein, in dem das explizite Schützen des Konstruktors helfen sollte. Denn wie du selbst sagst, dazu müssten zwei Threads gleichzeitig das selbe (und nicht nur das gleiche) Objekt erzeugen, was ausgeschlossen ist. Denn, selbst wenn du Seiteneffekte im Konstruktor hast, müsste das Ziel der Seiteneffekte Thread-Safe sein und nicht der Konstruktor selbst. Ansonsten hindert dich ja nichts daran das genannte "Ziel" gleichzeitig aus nem anderen Thread zu bearbeiten. Daneben hilft dein Ansatz auch nicht, wenn du gleichzeitig zwei verschiedene Instanzen der selben Klasse erzeugst, wenn im Konstruktor eine nicht thread-safer Seiteneffekt ausgeführt wird, da es sich m zwei unterschiedliche CriticalSections handelt.

mfg

Christian

Kann mir einer mal ein Beispiel nennen, wo ein Konstruktor knallen kann, weil 'er noch nicht fertig ist'?

Wenn ich schreibe: Foo := TMyThread.Create; Hat Foo erst dann einen Wert, wenn der Konstruktor fertig ist.

Da es eine Grundregel gibt, die besagt, das Konstruktoren keinen logischen Code beinhalten sollen, kann ich mir irgendwelche komplex konstruierten Gebilde sparen, wo ich vielleicht doch auf ein Objekt zugreife, dessen Konstruktor noch nicht abgearbeitet ist, z.B.:

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TMyThread.Create (aSomeObject : TSomeObject);
Begin
  ...
  aSomeObject.CallMe(Self);
...
End;

Procedure TSomeObject.CallMe (aThread : TMyThread);
Begin
  aThread.Bang();
End;

So, dagegen kann man sich also absichern, ja? Wozu? Sowas macht man einfach nicht:

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TMyThread.Create (aSomeObject : TSomeObject);
Begin
  ...
  FSomeObject := aSomeObject;
...
End;

Procedure TMyThread.Initialize();
Begin
  FSomeObject.CallMe(Self);
End;

Procedure TSomeObject.CallMe (aThread : TMyThread);
Begin
  aThread.Bang();
End;

Der Verwender des TMyThread muss eben Initialize() aufrufen. Und das kann er erst, wenn die Instanz (vollständig) instantiiert wurde.

Ich bleib dabei: Diese Gedankenspiele sind nett, aber lenken vom eigentlichen Problem ab. Sofern man das Gedankenspiel nicht als solches auffässt.

Wie wäre es mit Überlegungen, die Endlosschleifen erkennen?
While True do; Obwohl ich ein System kenne, das versucht, soetwas zu erkennen (so ein Schwachsinn).

Zitat von Furtbichler:

Kann mir einer mal ein Beispiel nennen, wo ein Konstruktor knallen kann, weil 'er noch nicht fertig ist'?

Du kannst sowas haben, wenn du im Konstruktor z.B. auf nen Parameter zugreifst und Self übergibst. In der VCL wird beispielsweise im Konstruktor das zu erzeugende Objekt dem Owner übergeben. So etwas wäre ein Fall, der Probleme machen kann. Aus diesem und ähnlichen Gründen ist die VCL nicht thread-safe.

Allerdings: Der oben beschriebene Ansatz löst dieses Problem, wie ich oben schon geschrieben habe, gerade *nicht*. Und ein paar andere Fälle löst er auch nicht. Im Grunde genommen gebe ich dir also damit recht, dass die CS im Konstruktor nichts bringt.

mfg

Christian

Zitat von r2c2:

Trotzdem fällt mir kein sinnvoller Fall ein, in dem das explizite Schützen des Konstruktors helfen sollte. Denn wie du selbst sagst, dazu müssten zwei Threads gleichzeitig das selbe (und nicht nur das gleiche) Objekt erzeugen, was ausgeschlossen ist.

Das mit den 2 Threads, die die gleiche Objekt-Instanz erzeugen, war als Antwort auf himitsu's Anmerkung, dass die Erzeugung der CS-Instanz nicht Thread-Safe ist und ich damit eigentlich nur aufzeigen wollte, dass dieser Fall nur in der Theorie vorkommen kann.

Der Schutz des Konstruktors wird dann wichtig, wenn man z.B. eine Klasse erzeugt, die z.B. einen Thread-Pool erstellt und diesem Thread-Pool auch sich selbst als Referenz mitgibt.

Hiermal als völlig ungeschützte Klasse:

zusammenfalten · markieren

Delphi-Quellcode:

TMyThreadPool = class
private
  _Pool : TList<TPoolThread>;
public
  constructor Create( PoolSize : integer );
  // Some Properties ...
end;

constructor TMyThreadPool.Create;
begin
  inherited Create;
  _Pool := TObjectList<TPoolThread>.Create;
  while _Pool.Count < PoolSize do
    _Pool.Add( TPoolThread.Create( Self ) );
  // Init Some Properties
end;

Mit meiner Lösung bekomme ich die Klasse 100% Thread-Safe mit relativ geringem Aufwand.
Eine Ableitung von der Klasse TMyThreadPool geht auch sehr charmant und bleibt 100% Thread-Safe

Man könnte hier natürlich darüber streiten, ob die Pool-Threads den Pool überhaupt kennen sollten, aber hier hast du recht. Immer, wenn man im Konstruktor einen Thread erzeugt und dem Self mitgibt hat man das Problem und deine Lösung hilft hier. OK, verstanden.

mfg

Christian

Ich bleibe dabei: Trenne Instantiierung von Initialisierung und man hat viel mehr Zeit für andere Sachen. Weil man sich nicht mit solchem "Quark" beschäftigen muss. Wobei das Problem an sich schon recht interessant ist.

Zitat von Furtbichler:

Ich bleibe dabei: Trenne Instantiierung von Initialisierung und man hat viel mehr Zeit für andere Sachen. Weil man sich nicht mit solchem "Quark" beschäftigen muss.

Kommt drauf an. Wenn die Instanziierung ausreicht, um das Objekt in nen konsistenten zustand zu versetzen, ist das OK und oft die bessere Lösung. Wenn man immer initialize() aufrufen muss, hat man ne weitere Fehlerquelle geschaffen, was ich definitiv vermeiden würde.

mfg

Christian