AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Allgemeine Fragen zu Thread-Safety

Ein Thema von s.h.a.r.k · begonnen am 18. Jul 2011 · letzter Beitrag vom 18. Jul 2011
Antwort Antwort
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#1

Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 12:56
Hallo zusammen,

ich habe im Moment immer wieder das Problem, dass ich nicht so recht weiß, ob hier oder da was absichern muss oder nicht. Hier mal ein paar Beispiele, bei denen mir das irgendwie nicht so recht klar ist. Bitte immer mit Begründung antworten und nicht rein aus dem Bauch heraus

Eines noch vorab: Lock() = FCriticalSection.Enter(), Unlock() = FCriticalSeciton.Leave().
  1. Konstruktoren: Welche der beiden Methoden sollte genutzt werden?
    Delphi-Quellcode:
    constructor TMyObject.CreateA();
    begin
      Lock();
      try
        inherited Create();
        FMemberA := 1;
        FMemberB := 'Delphi';
        Blub();
        Bla();
      finally
        Unlock();
      end;
    end;

    // oder

    constructor TMyObject.CreateB();
    begin
      inherited Create();
      FMemberA := 1;
      FMemberB := 'Delphi';
      Blub();
      Bla();
    end;
  2. Destruktoren: Zunächst ist mir klar, dass diese abgesichert werden sollten, da mehrere Threads ja auch die gleichen Ressourcen zugreifen können. Allerdings erscheint doch imho eine Exception, wenn ein Thread das Objekt freigibt und ein zweiter lesen will. Folgendes Beispiel: Thread A ruft Destroy auf und Thread B den Getter für Stupid. Thread A erhält den Vorang und Thread B muss somit beim Lock des Getter warten. Lustig wirds da dann, wenn Thread A Unlock() verlassen hat und dann die CriticalSection freigibt, während Thread B dann ja eigentlich lesen darf und die CriticalSection benötigt. Hier mal der Code dazu:
    Delphi-Quellcode:
    function GetStupid(): string;
    begin
      Lock();
        Result := FStupid;
      finally
        Unlock();
      end;
    end;

    destructor TMyObject.Destroy();
    begin
      Lock();
      try
        FreeAllThings();
        CleanTheKitchen();
        inherited Destroy();
      finally
        Unlock();
        FCriticalSection.Free();
      end;
    end;
    Insgesamt würde ich sagen, dass sobald so eine Situation auftritt, es sich um ein Designfehler handelt und dieses Konzept überdacht werden sollte. Daraus schließe ich aber, dass man einen Destruktor ja gar nicht absichern muss, da es ja eigentlich immer krachen wird.

  3. Einfacher verschachtelter Aufruf: Passt das so, oder muss ich die zweite A-Methode auch noch mit Lock()/Unlock() absichern? Hier wird ja nur eine Variable einfachen Typs übergeben.
    Delphi-Quellcode:
    procedure TMyObject.A(Param: Integer);
    begin
      Lock();
      try
        DoSomething(Param);
      finally
        Unlock();
      end;
    end;

    procedure TMyObject.A();
    var
      i : Integer;
    begin
      i := 10;
      A(i);
    end;
  4. Komplexerer verschachtelter Aufruf:
    (a) Eigentlich die gleiche Frage, wie unter 3., allerdings hier noch eine Stufe mehr verschachtelt und mit einem Objekt und Record anstatt eines einfachen Typs.
    (b) Angenommen DoSomething() würde das Param-Objekt in einen threadsicheren Puffer pushen und nichts anderes anstellen, bräuchte ich dann das Lock() und Unlock() doch nicht, oder?
    Delphi-Quellcode:
    procedure TMyObject.A(Param: TObject; FS : TFormatSettings);
    begin
      Lock();
      try
        DoSomething(Param, FS);
      finally
        Unlock();
      end;
    end;

    procedure TMyObject.A(Param: TObject);
    var
      FS : TFormatSettings
    begin
      FS := SysUtils.FormatSettings;
      A(Param, FS);
    end;

    procedure TMyObject.A();
    var
      Obj: TObject;
    begin
      Obj := TObject.Create()
      A(Obj);
    end;
Ich glaub, das wars fürs erste
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von chaosben
chaosben

Registriert seit: 27. Apr 2005
Ort: Görlitz
1.358 Beiträge
 
Delphi XE2 Professional
 
#2

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 13:02
Zu Punkt 1 und 2:
Erzeugen und und freigeben sollte immer nur einer. Alles andere ist imho, wie du schon festgestellt hast, ein Designfehler.
Beim Konstruktor ist es noch einfacher: solange der sich noch nicht zurückgemeldet hat, weiß ja niemand von dem neuen Objekt. Also kann es innerhalb des Objektes keine Kollision geben.

3.: Passt so.
Benjamin Schwarze
If I have seen further it is by standing on the shoulders of Giants. (Isaac Newton)

Geändert von chaosben (18. Jul 2011 um 13:14 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#3

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 13:10
5. Nicht (unbedingt) threadsichere Methoden: Ich habe gerade einen Konstruktor geschrieben, der die Format-Methode nutzt. Ich weiß ja pauschal nicht, ob diese Methode threadsafe ist oder nicht. Daher hätte ich dann diesen Code ...
Delphi-Quellcode:
constructor TMyObject.Create(const AFormat: string; const Args: array of const);
begin
  inherited Create();
  FMessage := Format(AFormat, Args);
end;
... wie folgt umgeschrieben. Dieses Problem ist ja auch auf jede andere beliebige Methode "anwendbar" und nich auf Konstruktoren beschärnkt.
Delphi-Quellcode:
constructor TMyObject.Create(const AFormat: string; const Args: array of const);
begin
  inherited Create(); // Erzeugt eine CriticalSection, da von
                      // entsprechender Basisklasse abgeleitet
  Lock();
  try
    FMessage := Format(AFormat, Args);
  finally
    Unlock();
  end;
end;
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von chaosben
chaosben

Registriert seit: 27. Apr 2005
Ort: Görlitz
1.358 Beiträge
 
Delphi XE2 Professional
 
#4

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 13:17
5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.

PS: Mir scheint das Problem besteht bei allen anderen Beispielen auch.
PPS: Bei einem zeitkritischen Projekt habe ich mal festgestellt, das TCriticalSection entschieden langsamer war, als RTL_CRITICAL_SECTION. Warum konnte ich leider nicht ergründen
Benjamin Schwarze
If I have seen further it is by standing on the shoulders of Giants. (Isaac Newton)

Geändert von chaosben (18. Jul 2011 um 13:21 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.373 Beiträge
 
Delphi 12 Athens
 
#5

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 13:22
Ich habe gerade einen Konstruktor geschrieben, der die Format-Methode nutzt. Ich weiß ja pauschal nicht, ob diese Methode threadsafe ist oder nicht.
1. hat das gar nichts mit dem Konstruktor zu tun, sondern gilt für jeden Aufruf von Format aus verschiedenen Threads.

2. nimmt man deswegen immer die threadsichere Variante von Format, bei der man die FormatSettings mit angibt. Es ist nämlich nicht der Code von Format, der nicht threadsicher ist, sondern die Verwendung der globalen FormatSettings.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#6

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 13:38
Ich habe gerade einen Konstruktor geschrieben, der die Format-Methode nutzt. Ich weiß ja pauschal nicht, ob diese Methode threadsafe ist oder nicht.
1. hat das gar nichts mit dem Konstruktor zu tun, sondern gilt für jeden Aufruf von Format aus verschiedenen Threads.

2. nimmt man deswegen immer die threadsichere Variante von Format, bei der man die FormatSettings mit angibt. Es ist nämlich nicht der Code von Format, der nicht threadsicher ist, sondern die Verwendung der globalen FormatSettings.
Ich habe diese Format-Methode leider nicht bis ins letzte Details ergründet, da dort auch irgendwann mal mit Assembler hantiert wird. Aber danke für den Hinweis. Habe gerade auch den Quellcode-Kommentar von TFormatSettings gelesen. Irgendwie muss man bei Threads viel zu viel beachten

5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.

PS: Mir scheint das Problem besteht bei allen anderen Beispielen auch.
Stimmt... D.h. ich muss mir somit für dies Format-Methode einen threadsicheren Wrapper basteln, oder wie Uwe Raabe vorgeschlagen hat, die Format-Methode immer mit dem FormatSettings-Parameter aufrufen.

PPS: Bei einem zeitkritischen Projekt habe ich mal festgestellt, das TCriticalSection entschieden langsamer war, als RTL_CRITICAL_SECTION. Warum konnte ich leider nicht ergründen
Dank für die Info. Interessant wäre jetzt noch zu wissen, wie hoch der Geschwindigkeitsgewinn denn gewesen ist?
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von chaosben
chaosben

Registriert seit: 27. Apr 2005
Ort: Görlitz
1.358 Beiträge
 
Delphi XE2 Professional
 
#7

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 14:13
Tschaa ... jetzt wolle ich ne kleine Demoapp schreiben (bezüglich der Zeit) und da taucht das Problem nicht mehr auf.
Mal sehen, vielleicht finde ich die alten Sourcen noch mal.
Benjamin Schwarze
If I have seen further it is by standing on the shoulders of Giants. (Isaac Newton)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.558 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 15:54
5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.
Die könnte man als class var speichern und dafür im class contructor initialisieren und im class destructor wieder freigeben.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#9

AW: Allgemeine Fragen zu Thread-Safety

  Alt 18. Jul 2011, 16:29
Tschaa ... jetzt wolle ich ne kleine Demoapp schreiben (bezüglich der Zeit) und da taucht das Problem nicht mehr auf.
Mal sehen, vielleicht finde ich die alten Sourcen noch mal.
TCriticalSection ist eigentlich nur ein Wrapper für eine RTL_CRITICAL_SECTION, ergo wird das wohl gleich schnell sein. Muss daher wohl am Projekt selbst gelegen haben.

5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.
Die könnte man als class var speichern und dafür im class contructor initialisieren und im class destructor wieder freigeben.
Jup, das ist klar. Aber bevor ich da jeder Klasse eine extra CriticalSection mitgebe, schreibe ich mir da dann doch liebe einmal eine threadsichere Methode, die das Format eben entsprechend kapselt
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  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 18:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz