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 17:05 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