Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Threads immer zwingend syncronisieren ? (https://www.delphipraxis.net/70058-threads-immer-zwingend-syncronisieren.html)

DataCool 24. Mai 2006 12:54


Threads immer zwingend syncronisieren ?
 
Hi Leute,

ich bin gerade dabei eine Komponente zu schreiben, die vereinfacht gesagt nichts anders macht als eine
TCP/IP Connection (IdTcpClient Indy9) zu einem Server aufzubauen und
Datenpakete zum Server zu Senden und zu Lesen.

Die Kommunikation mit dem Server ist asycron, d.h. nicht immer nach Senden einer Anfrage kommt
auch sofort die entsprechende Antwort.
Das liegt daran das der Server selber auch Events in die Connection schreibt.

Jetzt habe ich innerhalb meiner Komponente einen Thread erzeugt der eigentlich nichts anders macht als :

Delphi-Quellcode:
procedure TTwConnection2SvrThread.Execute;
Var sTmp : String;
    tmpErr : TConnectionThreadError;
begin
  While (not Terminated) and (fTcpCon.Connected) do begin
    tmpErr := teNoError;
    try
      sTmp := Trim(fTcpCon.ReadLn(#$A,250));
    except
      tmpErr := teReadLnException;
      sTmp := '';
    end;
    if tmpErr <> teNoError then begin
      if not fTcpCon.Connected then
        tmpErr := teConnectionLost;
      if Assigned(FOnThreadError) then
        FOnThreadError(self,tmpErr);
    end
    else begin
      // any kind of data ?
      if sTmp <> '' then begin
        // fire different with different paramter
        // use Synchronize or NOT ????
      end;
    end;
  end;
end;
Es wird also immer aus der Connection gelesen und wenn Daten vorhanden sind sollen unterschiedliche Events ausgelöst werden, aber alle Events mit unterschiedlichen Parametern.

Normalerweise sollten diese Events ja alle syncronisiert aufgerufen werden,
anderseits werden nie mehere Events gleichzeitig aufgerufen, weil der Thread ja nur immer ein Event zur Zeit auslösen kann. Da es jetzt aber gut möglich seien kann, das bei einigen Events GUI-Elemente in irgenteiner Form geändert werden spricht das wieder für die Verwendung von Synchronize, oder sehe ich das falsch ?

Was meint Ihr synchronize verwenden oder nicht ?

Bei der Verwendung von Synchronize hat jemand ne gute Idee wie ich es umgehen mir für jedes Events eine extra Synchronize procedure ohne Parameter zu schreiben ?

Danke und Gruß

Data

DataCool 26. Mai 2006 09:52

Re: Threads immer zwingend syncronisieren ?
 
*push*, niemand ne Meinung dazu ?

Gruß Data

Hudel1965 26. Mai 2006 10:31

Re: Threads immer zwingend syncronisieren ?
 
Hi :)

Wenn in diesem Event irgendwelche VCL Dinge verwendet werden, muss du Synchronize verwenden, egal ob du nur ein Thread läuft bzw. nur ein Event ausgelöst wird, die VCL ist halt nicht Thread safe.

Gruß

Hudel

Frickeldrecktuxer_TM 26. Mai 2006 10:59

Re: Threads immer zwingend syncronisieren ?
 
Zitat:

Zitat von DataCool
Normalerweise sollten diese Events ja alle syncronisiert aufgerufen werden,

Depends ;-)
Wenn du einen Thread erzeugst, erzeugst du einen neuen Ausführungskontext (kein ganzer Prozess, aber ein bisschen ;-)). Alles, was du aus diesem Thread heraus an Funktionen aufrufst, wird innerhalb dieses Threads ausgeführt, unabhängig davon, ob es Event-Handler aus anderen Klassen sind, Interaktionen mit der VCL oder sonstwas.
Wenn du deinen Eventhandler ohne Synchronize() aufrufst, wird der handler also innerhalb deines Threads ausgeführt. In dem Fall muss dann der Autor des Handlers für die Threadsynchronisation sorgen, wenn er auf Fariablen zugreifen will, die möglicherweise von anderen Threads konkurrierend verwendet werden.

Zitat:

Zitat von DataCool
Was meint Ihr synchronize verwenden oder nicht ?

Eindeutig für Synchronize(), und zwar aus zweierlei Gründen:
Es ist üblich, daß Klassen für den Programmierer transparent sind. Deine Klasse könnte genausogut Application.OnIdle aunutzen, um "im Hintergrund" zu arbeiten, ohne einen neuen Thread abzuspalten. Als Delphi-Programmierer geht man erstmal von eienr single threaded application aus, man würde also erwarten, daß die Eventhandler, die man verknüpft, auch innerhalb des für den Programmierers hauptsächlich sichtbaren Kontexts ausgeführt werden. Die logische Folge ist: Ich bin in Thread A (das muss nichtmal der Haupt-Thread sein, deine Klasse lässt sich ja auch anderswo instanzieren), erzeuge eine Klasse und verknüpfe Eventhandler, dann erwarte ich auch, daß meine Handler in meinem Thread A ausgeführt werden. Du würdest hier einen logischen Bruch erzeugen, indem du selbst einen Thread B erzeugst und die Handler dann in Thread B ausführen würdest.
Das wäre der rein design-orientierte Grund. Ein weiterer ganz praktischer Grund wurde schon von Hudel1965 genannt: Du weißt nicht, was im Eventhandler steht (in deiner Anwendung vielleicht schon, aber wenn du die Klasse später mal einem anderen Programmierer aushändigst...). Wenn Zugriffe auf die VCL stattfinden, sollten diese mit dem Haupt-Thread synchronisiert werden. Aus obigen Überlegungen heraus greift man üblicherweise einfach auf die VCL-Objekte zu und schickt nicht zu Fuß asynchrone Nachrichten an die NAchrichtenschleife, um ein VCL-Element zu verschieben. In dem Fall muss auf jeden Fall ein Synchronize() mit dem Haupt-Thread erfolgen. Eventuell werden aber die gleichen Eventhandler für andere Events verwendet oder man will vorhandenes Design mit deiner Klasse erweitern. Das Synchronize() in die Handler auszulagern ist also wenig sinnvoll.


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:11 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz