AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

CriticalSection und Threads

Ein Thema von Sir Rufo · begonnen am 26. Nov 2011 · letzter Beitrag vom 26. Nov 2011
Antwort Antwort
Seite 2 von 2     12
Furtbichler
(Gast)

n/a Beiträge
 
#11

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 13:07
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.:

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?
While True do; Obwohl ich ein System kenne, das versucht, soetwas zu erkennen (so ein Schwachsinn).
  Mit Zitat antworten Zitat
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#12

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 13:20
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
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
2.916 Beiträge
 
Delphi 2009 Professional
 
#13

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 15:33

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.
Michael Justin
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#14

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 16:08
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
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#15

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 16:31
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
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#16

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 18:47
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.
  Mit Zitat antworten Zitat
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#17

AW: CriticalSection und Threads

  Alt 26. Nov 2011, 20:07
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
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:44 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf