Application.ProcessMessages über Synchronize in Thread erlaubt?

[berens]

Hallo!
Darf ich so etwas machen, oder "nicht-gut"?

Delphi-Quellcode:

 
procedure TMeinThread.Execute;
begin

 // hier kommt der Thread-Quelltext hin


 Synchronize(BinFertig);
end;


procedure TMeinThread.BinFertig;
begin
  Application.ProcessMessages;
  frmMain.ZeichneUebersichtNeu;
end;

Das Application.ProcessMessages muss dahin, weil einige Operationen (ADO etc.) noch nicht abgeschlossen sind, wenn ich direkt frmMain.ZeichneUebersichtNeu aufrufe.

Klar, ich könnte Application.ProcessMessages auch in der ersten Zeile von frmMain.ZeichneUebersichtNeu aufrufen, aber mich interessiert halt hier konkret, ob sich der Thread hier festfahren könnte, wegen Application.ProcessMessages (äh "Interlock", oder wie heißt das?).

Da BinFertig über Synchonize aufgerufen wird, sollte ja nichts schlimmes passieren, oder?

[Bummi]

Sinn oder Unsinn dahingestellt, alles im Synchronize findet im Haupthread statt und ist somit unkritisch

[berens]

Danke für die Antwort, das klärt das Thema abschließend. :-D

[WladiD]

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Benutze lieber einen Timer oder meinetwegen meine TDelayedMethod-Klasse:

Delphi-Quellcode:

procedure TMeinThread.Execute;
begin
 Synchronize(BinFertig);
end;


procedure TMeinThread.BinFertig;
begin
  TDelayedMethod.Execute(frmMain.ZeichneUebersichtNeu); // Wird über WM_TIMER ausgeführt (also niedrigste Prio)
end;

[Luckie]

Zitat:

Zitat von WladiD (Beitrag 1172840)

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Kannst du das auch begründen? Was ist dagegen einzuwenden die Nachrichtenschlange abzuarbeiten, wenn einem danach ist?

[Namenloser]

Sollte gehen, aber irgendwie erscheint mir das widersinnig, da Synchronize ja intern schon so funktioniert, dass eine entsprechende Synchronize-Message mit einem Methoden-Pointer an den Message-Queue der Anwendung angehängt wird. D.h. eventuell wäre es sinnvoller, das Synchronize einfach erst etwas später im Code auslösen, wenn die restlichen Operationen abgeschlossen sind.

[mjustin]

Zitat:

Zitat von Luckie (Beitrag 1172886)

Zitat:

Zitat von WladiD (Beitrag 1172840)

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Kannst du das auch begründen? Was ist dagegen einzuwenden die Nachrichtenschlange abzuarbeiten, wenn einem danach ist?

Man muss natürlich auch die Risiken und Nebenwirkungen kennen - mindestens muss man daran denken, bei längeren Aktionen die Application.ProcessMessages nutzen umd die Oberfläche nicht 'einzufrieren', alle Eventhandler vorübergehend "auszuschalten", die sonst erneut die gleiche Aktion aufrufen würden.

In vielen Fällen ist Application.ProcessMessages ein Hinweis auf Code, der in einem Thread übersichtlicher, schneller, und mit geringerem Risiko von Nebenwirkungen laufen würde.

[BUG]

Threads sind nicht die Lösung für alle Probleme.
Was macht der neue Thread hier? Er wartet (hoffentlich) auf die DB, um dann synchronisiert auf der Mainform rumzumalen. Super, das gleiche Problem, nur mit einem Thread mehr :wink:

Dabei ist das Ganze ein Synchronisierungsproblem, das ich mit einem Zustandsautomat lösen würde:

Anhang 37185

Eingaben des Automaten:

• queryDB: Anfrage an DB wurde gestartet
• DBfinished: ADO ist fertig
• planRepaint: dein Thread macht das Synchronize

Ausgaben des Automaten:

• doRepaint(): das was du eigentlich machen wolltest

Es wäre mehr als merkwürdig, wenn dir queryDB und DBfinished nicht irgendwo mitgeteilt würden (-> Ereignisse). Die Übergänge die nicht eingezeichnet sind, sollten Fehlerfälle sein.


Zwei boolesche Flags würden es auch tun, aber so ist es aussagekräftiger und kann gut um weitere Zustände ergänzt werden.

[berens]

Also ich habe mich mit der Notwendigkeit von Application.ProcessMessages in meinem konkreten Fall nicht weiter beschäftigt. "Mit" geht es, "ohne" halt nicht.

Mein Thread speichert einen (neuen) Eintrag in ein TAdoQuery in einer Access (.mdb) Datenbank. Wenn AdoQuery.Post durchgeführt wurde, und das AdoQuery und die AdoConnection wieder freigegeben sind, wird über Synchronize die Prozedur oben aufgerufen, welche die Übersicht mit den Tabelleneinträgen neu zeichnet ( == neue Abfrage durchführen, dieses Mal ohne Thread).

Ohne Application.ProcessMessages wird der gerade gespeicherte Eintragt nicht mit angezeigt. AdoQuery.Post ist ja abgeschlossen, also müssen die Daten ansich schon in der Tabelle stehen. Tun sie aber scheinbar "noch" nicht. Ein manuelles Neu-Zeichnen eine Sekunde später schafft Abhilfe. Mit der Verwendung von Application.ProcessMessages vor dem Neuzeichnen scheint alles problemlos zu funktionieren; der neue Eintrag wird direkt angezeigt.

Hm... habe ich mal irgendwo gelesen, dass ADO/COM/OLE/JET trotzdem immer irgendwie über den Haupt-Thread läuft? Das würde erklären, warum die Daten erst nach Application.ProcessMessages drinnen stehen.

Das Ganze ist zwar ein sehr interessantes Thema, allerdings kein offenes Problem. Bevor wir uns jetzt tot-spekulieren: Es funktioniert, und "irgendwie" kann man das Ganze bestimmt "professioneller" oder optimaler Programmieren - keine Frage.

Falls jemand fundierte Hintergrundinfos hätte, um dieses Phänomen zu erklären ware cool, aber so wie es jetzt ist funktioniert es, und -wie es bei Computern halt so ist- manchmal muss man halt akzeptieren, dass etwas funktioniert obwohl es nicht sollte (und anders herum), aber dann sollte man das auch einfach mal so hinnehmen und sich drüber freuen :thumb:

[Luckie]

Zitat:

Zitat von mjustin (Beitrag 1172889)

alle Eventhandler vorübergehend "auszuschalten",

Das musst du bei einem Thread auch.

[Sir Rufo]

Ist der Aufruf von BinFertig tatsächlich so zu verstehen, dass dieser am Ende von Execute aufgerufen wird?

Dann benutze doch einfach das Event OnTerminate, das wird immer dann gefeuert, wenn der Thread fertig ist ;)

btw. CoInitialize und CoUninitialize benutzt du aber schon?
Benutzt du im Thread die gleiche ADOConnection wie im Hauptthread?

[berens]

Zitat:

btw. CoInitialize und CoUninitialize benutzt du aber schon?

:stupid: Aber ich bitte dich, das ist ja wohl selbstverständlich! *Überall schnell einfüg*
^-- Hatte ich bisher nur verwendet, wenn ansonsten ne Fehlermeldung kam. Bei den Ado-Komponenten in einem Thread hab ich bisher noch nicht dran gedacht, sollte bei ActiveX/COM aber natürlich selbstverständlich sein :/

Zitat:

Benutzt du im Thread die gleiche ADOConnection wie im Hauptthread?

Bevor der Thread mit Resume gestartet wird ( bei Create war CreateSuspended = True), setze ich eine StringVariable für den ConnectionString. In Execute werden dann erst die TAdoConnection und das TAdoQuery erzeugt, und AdoConnection.Connectionstring = Variable gesetzt.

OnTerminate ist mir irgendwie nicht so ganz geheuer. Bei einem Thread der in Schleife läuft und nur durch den MainThread mit ".Terminate" beendet werden kann, da befürchte ich dass das Event zu früh kommen könnte (also z.B. wenn ich den Befehl .Terminate aufrufe, und nicht, wenn Execute die letzte Zeile abgearbeitet hat). Und bei FreeOnTerminate existiert das Callback-Objekt vielleicht schon nicht mehr, oder wenn OnTerminate auf eine Prozedur vom eigenen Thread geht, dass dieser schon wegen FreeOnTerminate freigegeben wurde, und die dem FreeOnTerminate-Ereignis zugewiesenen Prozedur kann nicht ausgeführt werden, das das Objekt (der Thread) schon freigegeben wurde. Nennt mich übervorsichtig, aber im Laufe der Jahre habe ich das Vertrauen in solche "Selbstverständlichkeiten" verloren. Wenn jemand mir garantiert, dass das mit FreeOnTerminate nicht der Fall ist, wäre das natürlich eine gute Alternative :wink:

[BUG]

Sollte das nicht funktionieren, wäre das ein Bug, über den wahrscheinlich schon einige gestolpert wären:

Zitat:

Zitat von http://docwiki.embarcadero.com/Libraries/en/System.Classes.TThread.OnTerminate

Occurs after the thread's Execute method has returned and before the thread is destroyed.

[WladiD]

Zitat:

Zitat von Luckie (Beitrag 1172886)

Zitat:

Zitat von WladiD (Beitrag 1172840)

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Kannst du das auch begründen? Was ist dagegen einzuwenden die Nachrichtenschlange abzuarbeiten, wenn einem danach ist?

Weil an der Stelle alle anstehenden Messages abgearbeitet werden. Das Schlimmste sind dann die WM_TIMER-Messages (TTimer und Konsorten) die mal dort, mal hier anschlagen und natürlich die Thread-Synchronisierung an sich. Das kann soviele Nebeneffekte (vor allem in einem gewachsenen Projekt) haben, das kann man sich gar nicht vorstellen. So einen Code zu debuggen ist die Hölle (spreche aus Erfahrung) > man kann schlicht vieles nicht reproduzieren. Da kann dann das Programm schonmal abhängig von der CPU-Taktfrequenz/Netzwerk etc. sich unterschiedlich verhalten.

Ich hab's schonmal gesagt: TApplication.Processmessages ist in seiner Form ein Designfehler > es hätte protected sein müssen, dann wären viele Delphi-Anwendung um einiges stabiler.

PS: Es gibt kein einiziges Problem, welches man ohne TApplication.Processmessages nicht lösen könnte, aber man bekommt welche, wenn man's nutzt. :lol:

[himitsu]

Und deshalb hab ich mir ein ProcessDrawMessages gebastelt, welche keine Timer, Synchronize oder Maus-/Tastenereignisse verarbeitet.

In unserem Programm ist ProcessMessages weit verbreitet und so konnten wenigsten einige Nebenefekte beseitigt werden, ohne gleich alles umbauen zu müssen und das ProcessMessages komplett zu entfernen.

Man nehme nur mal eine Timer, der alle 10 Sekunden zuschlägt, beim Debuggen landet man dann ständig dort drin.