CriticalSection und Threads

[Furtbichler]

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

Wenn ich schreibe:

Delphi-Quellcode:

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.:

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:

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?

Delphi-Quellcode:

While True do;

Obwohl ich ein System kenne, das versucht, soetwas zu erkennen (so ein Schwachsinn).

[r2c2]

Zitat:

Zitat von Furtbichler (Beitrag 1137955)

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

[mjustin]

Zitat:

Zitat von Sir Rufo (Beitrag 1137928)

Und hier das Interface mit der Thread-Klasse:

Wäre das nicht sehr viel einfacher mit System.TMonitor implementiert?

Jedes Objekt "enthält" ab Delphi 2009 ein "Lock", das wie eine Critical Section benutzt werden kann (und noch mehr kann wie z.B. PulseAll und Wait) - und es verfällt automatisch mit Ablauf der Objekt-Lebenszeit.

Dass Threads von außen nach ihrem Start aufgerufen werden erscheint mir ansonsten auch etwas ungewöhnlich - in welchem Status der Thread gerade ist, wenn man eine seiner Operationen aufruft, ist unbestimmt.

[Sir Rufo]

Zitat:

Zitat von r2c2 (Beitrag 1137950)

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:

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

[r2c2]

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

[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. Wobei das Problem an sich schon recht interessant ist.

[r2c2]

Zitat:

Zitat von Furtbichler (Beitrag 1138011)

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