|
Delphi-Version: XE4
For-Schleife im Thread wird nur einmal abgearbeitet
Hi,
ich habe einen Thread, mit eine IdTCPClient, der beim Start ein paar Daten aus dem Hauptprogramm senden soll. Deswegen habe ich dort eine for-schleife, die aus dem Hauptprogramm Daten holt, und per TCP versenden soll. Mir ist schon klar, dass das alles vielleicht noch nicht ganz richtig ist, aber es handelt sich ja hier auch noch nicht um eine finale Version. Ich greife auf eine ListView zu, und will für jedes Items eine TCP-Nachricht verschicken. Im Count steht auch definiv 6 drin, aber die Schleife wird nur einmal durchlaufen. Er senden auch genau dieses erste Item, bzw. einen String aus diesem Items. Aber danach macht er nicht weiter, der Thread scheint auch nicht mehr zu reagieren, jedenfalls empfängt der TCPClient dann keine Nachrichten mehr. Die ganze Writelog's müßt ihr euch mal wegdenken, die sind nur für mich da, damit ich sehen kann wann wer was macht (oder halt eben nicht). Hier mal meine Execute-Procedure:
Delphi-Quellcode:
Sieht alles noch sehr wüst aus, daran bitte nicht stören.
procedure TTCPThread.Execute;
var s,c: string; waage, command: string; i: Integer; begin Try //FTCPClient.BoundIP:=FBindIP; //FTCPClient.BoundPort:=FBindPort; FTCPClient.host:=FHost; FTCPClient.Port:=FPort; FTCPClient.ConnectTimeout:=2000; Synchronize( Procedure begin frm_main.Writelog('Init TCP-Connection'); end ); FTCPClient.Connect; if not FTCPClient.Connected then begin Synchronize( Procedure begin frm_main.Writelog('TCP-Verbindung fehlgeschlagen'); end ); Self.Terminate; end else begin Synchronize( Procedure begin frm_main.Writelog('TCP-Verbindung hergestellt'); end ); //Diese Schleife wird genau einmal durchlaufen //Es sind 6 Items in lv_waagen vorhanden //Es wird aber lediglich lv_waagen.Items[0] verarbeitet FCS.Acquire; for I := 0 to frm_main.lv_waagen.Items.Count-1 do begin Synchronize( Procedure begin frm_main.Writelog('Sende Register '+inttostr(i)+' von '+inttostr(frm_main.lv_waagen.Items.Count-1)); end ); FTCPClient.SendCmd('Register:'+frm_main.lv_waagen.Items[i].SubItems[2]+':@'); end; FCS.Release; end; while not Terminated do begin if FErgebnisList.Count>0 then SendeErgebnisse; if FTCPClient.IOHandler.InputBufferIsEmpty then begin FTCPClient.IOHandler.CheckForDataOnSource(100); FTCPClient.IOHandler.CheckForDisconnect; if FTCPClient.IOHandler.InputBufferIsEmpty then Continue; end; s:=FTCPClient.IOHandler.InputBuffer.ExtractToString; if s<>'' then begin Synchronize( Procedure begin frm_main.Writelog(s + ' von '+ FHost); end ); while Pos('@', s)>0 do begin c:=Copy(s,1,Pos('@',s)-1); s:=Copy(s,Pos('@',s)+1,Length(s)); if Pos(':',c)>0 then begin command:=Copy(c,1,Pos(':',c)-1); c:=Copy(c,pos(':',c)+1,Length(c)); waage:=Copy(c,1,Pos(':',c)-1); if lowercase(command)='st' then begin Synchronize( procedure begin frm_main.NachrichtenBufferAdd(FHost, FPort, s, command, waage, self); end ); end; end; end; end; //Sleep(1000); Self.Suspend; if Terminated then break; end; if FTCPClient.Connected then begin FTCPClient.SendCmd('Disconnect'); FTCPClient.Disconnect; end; finally if FTCPClient.Connected then begin FTCPClient.SendCmd('Disconnect'); FTCPClient.Disconnect; end; FTCPClient.Free; FErgebnisList.Free; FCS.Free; end; end; |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Funktioniert der Code denn auch wenn er nicht innerhalb eines Threads läuft?
Funktioniert es wenn die FCS (Critial Section) nicht benutzt wird? (Diese Critical Section in Verbindung mit einem Synchronize sieht nach einer Deadlockquelle aus). Es ist wahrscheinlich nicht die Ursache für die Hänger, aber FTCPClient.IOHandler.InputBuffer.ExtractToString sieht bedenklich aus, hier kann auch ein Teil des erwarteten Inhalts im InputBuffer stehen. Die Daten können, wenn man das Protokoll kennt, mit IOHandler.Read... Methoden aus dem Socket gelesen werden. Wenn man das Protokoll nicht kennt, hat man ein anderes Problem :) |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Da du im Execute keinerlei Exceptions verarbeitest, solltest du das dringend machen.
Try-Except drumrum und die Exception anzeigen. Tipp: TThread hat ein OnTerminate-Ereignis, welches du dringend mal implementieren solltest, da du Ersteres ja nicht machst. Und da drin dann einfach
Delphi-Quellcode:
Und nicht vergessen, dieser ShowException-Aufruf muß natürlich mit der VCL synchronisiert werden.
if Assigned(TThread(Sender).FatalException) then
ShowException(Exception(TThread(Sender).FatalException), nil); Ex gibt in der Unit System zwar ein End-Thread-Event, aber wenn Dieses ausgeführt wird, dann kann die Thread-Instanz schon weg sein (FreeOnTerminate) und selbst wenn noch nicht, dann kommt man dort sowieso nicht an den Instanzzeiger. :wall: |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Da steht in der Methode ein FCS.Free aber kein FCS := <...>.Create!
Die Mehrfachen blöcke mit
Delphi-Quellcode:
Sollte man mindestens in eine Threadfähige Queue stecken um eine bessere Entkopplung zu haben.
Synchronize(
Procedure begin frm_main.Writelog('....'); end ); |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
|
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Hi,
die CriticalSection hab ich erst hinzugefügt, als ich gemerkt habe dass meine Schleife nicht vollständig durchlaufen wird. Vorher gings aber auch nicht. das FTCPClient.IOHandler.InputBuffer.ExtractToString wird mit dem Fehler wohl nichts zu tun haben, denn mein Problem entsteht ja schon vorher. ich kann auch mit 100%Prozentiger Sicherheit sagen, dass sich an meinem ListView während der Thread gestartet wird nicht verändert. Dieses wird aufgebaut, bevor der Thread gestartet wird und auch keiner Stelle im Prog verändert. Interessant finde ich, dass 1. Auf dieses erste Item im LV ohne Fehler zugegriffen werden kann. 2. Auch der korrekte String gelesen wird 3. und diese auch von IdTCPClient korrekt versendet wird. Nur warum es dann nicht weiter geht, das ist mir ein Rätsel. Zitat:
Das mit Assigned(TThread(Sender).FatalException) hab ich grad mal gar nicht verstanden. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
1. Der Thread ist der einzige der darauf zugreift (weil ich nur einen erzeuge) 2. Auf das lv_waagen wird nach dem Füllen nicht mehr zugegriffen, und dieses passiert definitiv vor dem Erzeugen des Threads. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Mittlerweile habe ich folgendes herausgefunden:
Er bleibt beim FTCPClient.SendCmd hängen, weil: wenn ich die TCP-Verbindung vom Server aus trenne, dann läuft die Schliefe anschließen genau die 6 mal durch, jedoch schlägt dann das senden natürlich fehl. Mit FTCPClient.IOHandler.Writeln läufts dann durch. Durch Try Except hab ich das lokalisieren können. Danke himutsi. Allerdings kann ich nur einmal was empfangen. Also scheint im FTCPClient.IOHandler.InputBuffer.ExtractToString der nächste Fallstick zu liegen. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Zitat:
Dort gilt das alls GDI-Objekte nur im erzeugten Thread gültig sind. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Der Zugriff in der for-Schleife erfolgt eben nicht synchronisiert
|
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Ich weiß ja nicht wie ud wo die die Instanz deines Threads gespeichert hast, aber das ist ja egal, da der Sender immer passt und man die Instanz somit auch da auslesen kann. Man muß halt nur das TObject in den richtigen Typen casten, wenn man das verwendet. Ergebnis: Du erstellst dir eine passende Methode, rufst darin das Syncronize und auf darin dann den genannten Code. Und nun natürlich nur noch das Event dem Thread zuweisen.
Delphi-Quellcode:
procedure TDeineForm{oder dein TThread-Nachfahre}.MyThreadTerminate(Sender: TObject);
begin // TThread(Sender).Synchronize nehm ich jetzt mal nicht, da der Thread ja eigentlich schon beendet ist // und ich jetzt nicht genau weiß, ob was passieren könnte, auch wenn es vermutlich doch funktionieren könnte TThread.Synchronize(nil, procedure begin if Assigned(TThread(Sender).FatalException) then ShowException(Exception(TThread(Sender).FatalException), nil); end); end; PS: Wäre es nicht besser, wenn dein WriteLog im inneren prüft, ob es im Hauptthread läuft und sich notfalls selber synchroonisiert? (oder notfalls einfach immer blind synchronisieren ... das Synchronize prüft das intern bestimmt auch selber nochmal) Würde das Logging vereinfachen und so einige Codezeilen sparen. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Wird der TCPClient im Thread-Kontext erzeugt? Achtung: Im Thread-Konstruktor erzeugte Dinge sind nicht im Thread-Kontext, sondern in dem des Hauptthreads!!! Die meisten Komponenten, die irgendwie mit Sockets und ähnlichen WinAPIs hantieren sind oft nur in dem Kontext zu benutzen, in dem sie auch erstellt wurden. Ich bin damit schon mal mit SQL-Komponenten übel auf die Nase gefallen. Du musst diese in der Execute-Methode erstellen.
Dies ist zumindest eines der potenziellen Probleme die mir noch aufgefallen sind, das andere wurde schon genannt. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Möglicherweise besteht die Beschränkung (Verwendung nur im erzeugenden Thread) bei plattformgebundenen Komponenten wie ICS, die ein Windows Fensterhandle benötigen - aber mit ICS habe ich zuletzt 2008 kurz Kontakt gehabt. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Wobei diesesa andauernde Zugriff auf frm_main (und dann auch noch globale Variable :roll:) sagen wir mal: potential zur Verbesserung bietet. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Zitat:
Ich kenne bisher nur die Möglichkeit Daten an den Hauptthread mit Synchronize sicher zu übergeben. Geht das mit Funktionen auch? Ich kenne das nur mit procedure. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Delphi-Quellcode:
FCS.Acquire;
// nicht synchronisierter Zugriff auf eine VCL-Komponente for I := 0 to frm_main.lv_waagen.Items.Count-1 do begin Synchronize( Procedure begin // hier ist es synchronisiert frm_main.Writelog('Sende Register '+inttostr(i)+' von '+inttostr(frm_main.lv_waagen.Items.Count-1)); end ); FTCPClient.SendCmd('Register:'+frm_main.lv_waagen.Items[i].SubItems[2]+':@'); end; FCS.Release; Zitat:
|
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Gut, ich sollte vielleicht die gesamte Schleife synchronisieren. Zitat:
Möglicherweise geht das nur über Messages. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Weiterleiten und empfangen hört sich gut an, dann mach das doch auch so.
Der Thread empfängt aber z.B. nicht, sondern greift lustig in die GUI und bedient sich. Ein Control missbraucht man auch nicht als Datenspeicher, sondern als interaktives Element zum Anzeigen und Erfassen. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
Die For-Schleife liest erst alles aus und speichert sich den End-Wert zwischen. Die Start- und End-Werte werden also immer nur einmal zu Beginn abgerufen. Manchmal läuft die Schleife "intern" sogar rückwärts, da ein Vergleich mit 0 einfacher ist und man sich dafür nicht den Endwert extra speichern muß. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
|
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Wie ist denn nun der beste Weg, um
a) Daten vom Hauptthread an den Zielthread zu senden? b) Daten vom Hauptthread zu holen, wenn dieser die benötigt, sie aber nun mal zur Startzeit des Threads noch nicht existierten oder sich im Programmverlauf verändert haben? Daten vom Thread in den Hauptthread ist keine Problem, aber meine ursprüngliche Frage zielte auf die beiden o.g. Punkte ab. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Ich habe mir dafür folgendes angewöhnt:
Sowohl der Thread als auch die GUI führen Listen von Daten, die jeweils "Aufgaben" in die entsprechende Richtung sind. Diese Listen sind mit Critical Sections komplett abgesichert. Wenn der Thread der GUI etwas mitteilen will, werden die Infos in die entsprechenden Listen gepackt und eine Message an das Mainform geposted. (PostMessage(), NICHT SendMessage()!!!) (Wenn die Infos in WParam und LParam passen gerne auch ohne Liste.) Umgekehrt schreibt der GUI Thread einfach in die Listen des Arbeitsthreads, und dieser guckt in seiner Hauptschleife immer nach ob in den Listen Dinge zur Verarbeitung anstehen. Wenn es nur ein paar Arten von Daten sind, und die Zugehörigkeiten klar ersichtlich, bin ich so faul die Listen in die Form-Klasse bzw. die Thread-Klasse zu legen. Sauberer wäre ein eigenes Kommunikationsobjekt, dass sich dann auch komplett selbst um die Synchronisierung kümmert. (Die ist hier lebensnotwendig.) Ob dies immer der beste Weg ist will ich nicht beurteilen, und es gibt sicherlich zig andere ähnlich gute Lösungen. Mit dieser fahre ich zumindest bisher sehr gut. |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Das heißt, ich definiere mir sowohl im Hauptthread als auch im Arbeitsthread einfach eine TStringList (oder möglicherweise auch eine TObjectList?) in die ich in beiden Richtungen mittels TCriticalSection gesichert schreiben kann.
Zitat:
|
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Was für Listen genau hängt natürlich davon ab, was du für Daten hin und her schieben willst. Ich habe meist eine Hand voll kleiner Daten-Klassen, die die nötigen Infos aufnehmen, und werfe diese dann in meine Listen. Wenn es nur um Strings geht, ist eine StringList natürlich angenehm fertig.
Um den zweiten Teil zu erklären mal zwei Code-Fetzen: Zum einen die "faule" Variante:
Delphi-Quellcode:
Und etwas netter:
{uDataLists.pas}
TMyDataContainer = class public x, y, z: Integer; end; {uMyThread.pas} TMyThread = class(TThread) private MainForm: THandle; // Im Konstruktor übergeben, dann kann das von PostMessage genutzt werden, und der Thread könnte jedes beliebige Form bedienen. ... public MainFormDataList: TList<TMyDataContainer>; ... end; {uMainForm.pas} TMainForm = class(TForm) private ThreadDataList: TList<TMyDataContainer>; MyThread: TMyThread; ... public ... end;
Delphi-Quellcode:
Die Datencontainerklassen müssen natürlich nicht identisch sein, ich wollte es nur nicht noch länger machen. Bei der faulen Variante halst man sich ggf. im Nachgang mehr Arbeit auf, da die gesamte Synchronisation noch passieren muss. Alternativ erstellt man sich eine generische Listenklasse, die von sich aus alle Zugriffe synchronisiert. Das sieht nach einem Haufen Vorbau aus, erspart einem später aber Ärger mit der Sync und ist im Handling dann später wirklich geschmeidig. Dieser Weg erhebt aber keinen Anspruch auf Allgemeingültigkeit, es gibt sicherlich Szenarien, in denen das völlig verkehrt sein kann. Bei mir passte eine solche oder ähnliche Struktur halt sehr oft ins Konzept.
{uDataLists.pas}
TMyDataContainer = class public x, y, z: Integer; end; {uThreadCommunications.pas} TMyThreadToFormCommunicator = class private class var FFromFormToThread: List<TMyDataContainer>; class var FFromThreadToForm: List<TMyDataContainer>; class var FCriticalSection: TCriticalSection; public class procedure PutInFormToThread(aDataContainer: TDataContainer); class function GetFromFormToThread: TDataContainer; ... end; class procedure TMyThreadToFormCommunicator.PutInFormToThread(aDataContainer: TDataContainer); begin FCriticalSection.Enter; try FFromFormToThread.Add(aDataContainer); finally FCriticalSection.Leave; end; end; class function TMyThreadToFormCommunicator.GetFromFormToThread: TDataContainer; begin FCriticalSection.Enter; try if FFromFormToThread.Count > 0 then begin result := FFromFormToThread.Items[0]; FFromFormToThread.Remove(result); end else result := nil; finally FCriticalSection.Leave; end; end; {uMyThread.pas} TMyThread = class(TThread) private MainForm: THandle; // Im Konstruktor übergeben, dann kann das von PostMessage genutzt werden, und der Thread könnte jedes beliebige Form bedienen. ... public ... end; procedure TMyThread.Execute; begin repeat try if FormNeedsUpdate then begin TMyThreadToFormCommunicator.PutInThreadToForm(currentDataContainer); PostMessage(FMainForm, WM_THREADUPDATE, 0, 0); end; if TMyThreadToFormCommunicator.FromFromToThreadCount > 0 then begin // Ob man hier immer nur ein Element verarbeitet oder sofort alle anstehenden ist Ermessenssache und vom genauen Zweck anhängig dataContainer := TMyThreadToFormCommunicator.GetFromFromToThread; DoStuffWith(dataContainer); dataContainer.Free; end; Sleep(1); // CPU Zeit abgeben um 100%-Auslastung in ruhigen Phasen zu vermeiden except // Allgemeine Exceptionbehandlung end; until Terminated; end; // Thread nutzt dann TMyThreadToFormCommunicator.PutInThreadToForm() und TMyThreadToFormCommunicator.GetFromFormToThread {uMainForm.pas} TMainForm = class(TForm) private MyThread: TMyThread; procedure ThreadUpdateHandler(var Msg: TMessage); message WM_THREADUPDATE; ... public ... end; procedure TMainForm.ThreadUpdateHandler(var Msg: TMessage); var dataContainer: TMyDataContainer; begin dataContainer := TMyThreadToFormCommunicator.GetFromThreadToForm; DoStuffWith(dataContainer); dataContainer.Free; end; // Form nutzt dann TMyThreadToFormCommunicator.PutInFormToThread() und TMyThreadToFormCommunicator.GetFromThreadToForm |
AW: For-Schleife im Thread wird nur einmal abgearbeitet
Zitat:
und dann veröffentlicht es diese Exception, über das Property FatalException, welches man im OnTerminate auslesen und anzeigen kann. OnTerminate wird von TThread bereits mit der VCL synchronisert (ist eigentlich voll blöd, daß es immer automatisch passiert, denn man braucht/will das nicht immer so haben), also kann man darin problemlos direkt die
Delphi-Quellcode:
anzeigen/loggen, oder man verwendet den Fehlerdialog der VCL (ShowException).
Exception(MyThread.FatalException).Message
Windows beendet Programme (schießt sie hart ab), bei denen eine Exception bis zur Wurzel (Windows) durchrauscht. Drum sollte man auch immer die SysUtils einbinden, um die Exception-Behandlung vom Delphi zu aktivieren. Denn selbst wenn man eine kleine "billige" DLL hat, in Welcher (in exportierter Prozedur) eine Exception auftritt, dann würde Windows das Programm abschießen, da die DLL (standardmäßig) nicht weiß, ob sie in einem Delphi-Programm geladen ist und ob sie nicht vielleicht dessen Fehlerbehandlung mit benutzten könnte. (siehe Delphi-OH > Verwendung von DLLs) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 13:06 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