Zitat von r2c2:

Warum haben deine Konstruktoren denn überhaupt Seiteneffekte? Denn nur dann braucht man ja die CriticalSections.

mfg

Christian

Wenn ich in meiner Anwendung keine Threads benutze, dann kann ich mir das sparen - richtig.

Aber wenn ich Thread-Safe Objekte benötige, dann könnten auch die Konstruktoren Seiteneffekte haben, je nachdem was ich im Konstruktor mache.
z.B. könnte ich dort die Instanz an einen bestehen Thread übergeben
Wäre der Konstruktor also nicht geschützt, dann würde es sofort knallen, wenn ich mit dem Konstruktor noch nicht fertig bin und der Thread schon auf meine Instanz zugreift.
Ich stelle einfach damit sicher, das es nicht knallen kann.

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.

Warum sollte man eine Klasse so deklarieren?

zusammenfalten · markieren

Delphi-Quellcode:

TFoo = class // Ableitung von TObject
public
  constructor Create;
end;

constructor TFoo.Create;
begin
  inherited; // wofür sollte das gut sein, denn TObject.Create beinhaltet nichts

  // irgendwas

end;

Ganz einfach, im Moment beinhaltet der Konstruktor von TObject keinen Code, aber er könnte irgendwann mal Code haben und ich bin auch in Zukunft safe.

zusammenfalten · markieren

Delphi-Quellcode:

function TMyThreadA.CS: TCriticalSection;
var
  Comp: TCriticalSection;
begin
  Result := _CS;
  if not Assigned(Result) then begin
    Result := TCriticalSection.Create;
    Comp := InterlockedCompareExchangePointer(Pointer(_CS), Pointer(Result), nil);
    if Assigned(Comp) then begin
      Result.Free;
      Result := Comp;
    end;
  end;
end;

Braucht keine zusätzliche CS.

Nur im Destructor, vor dem Freigeben der CS, diese dort besser nochmal mal sperren.

markieren

Delphi-Quellcode:

CS.Enter;
CS.Free;

Nicht daß sie noch in Benutzung ist, beim Freigeben.

Zitat von Sir Rufo:

Wenn ich in meiner Anwendung keine Threads benutze, dann kann ich mir das sparen - richtig.

Das ist klar; war aber nicht meine Aussage. Ich denke, man sollte Seiteneffekte in Konstruktoren eh möglichst vermeiden. Manchmal sind sie notwendig, aber häufig gibt es bessere Möglichkeiten. Furtbichler hat das ganze nochmal ausführlicher beschrieben: Wenn man sauber programmiert, braucht man sowas nur in Ausnahmefällen.

Zudem sind es ja normalerweise nicht die Threads, die Thread-Safe sein müssen, sondern die Objekte, auf die die Threads zugreifen.

Zitat:

z.B. könnte ich dort die Instanz an einen bestehen Thread übergeben

Einen Thread an einen anderen Thread übergeben? Ich versteh nicht, was du meinst. Aber klar, es gibt Fälle, in denen man Seiteneffekte braucht. Das will ich nicht bestreiten.

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.

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?

Zitat:

Warum sollte man eine Klasse so deklarieren?

zusammenfalten · markieren

Delphi-Quellcode:

TFoo = class // Ableitung von TObject
public
  constructor Create;
end;

constructor TFoo.Create;
begin
  inherited; // wofür sollte das gut sein, denn TObject.Create beinhaltet nichts

  // irgendwas

end;

Ganz einfach, im Moment beinhaltet der Konstruktor von TObject keinen Code, aber er könnte irgendwann mal Code haben und ich bin auch in Zukunft safe.

Da geh ich mit dir. Das hat mit der gegebenen Problematik aber wenig zu tun. Oder erwartest du, dass in TObject Seiteneffekte auftreten? Dann hättest du eh noch *ganz* andere Probleme. Auf so eine bescheuerte Idee wird Embarcadero zum Glück wohl eher nicht kommen. Das musst du nicht absichern.

mfg

Christian

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.