Code vom Thread in einen Timer umziehen?

[Jim Carrey]

Ich habe hier im Forum irgendwo mal gelesen, dass man, selbstverständlich, keine GUI-Änderungen in einem Thread abarbeitet. Und wenn, dann mit Synchronisation.

Ich habe einen Thread der bei einem längeren Prozess meine GUI immer anpasst. Genauer gesagt Captions, ProgressBars usw.
Ich habe hier auch irgendwo mal gelesen, dass man zum Beispiel im Thread A gewisse Variablen setzt (sagen wir mal Position der ProgressBar in einer Int-Variablen) und die in einem Timer auf der Mainform ausließt und setzt.

Weg vom Thread, der meine ProgressBar setzt und hin zum Timer auf der Mainform ja oder nein? Welche vorteile hätte das für mein Programm?

[Bambini]

Der richtige Weg wäre den Haupt-Thread mit der UI frei von Jobs zu halten.
Die Jobthreads synchronisieren die Progressbars und Caption selbst mit TThread.Synchronize(nil, ...)

[Jim Carrey]

Verstehe ich gerade nicht so ganz.
Wäre es also falsch einen Timer Variablen lesen zu lassen und die GUI verändern zu lassen?
Stattdessen alles im Thread mit Synchronize lassen?

[Der schöne Günther]

Nein, das wäre besser, denn somit hat dein Thread nur z.B. einen Wert "FortschrittInProzent" und muss sich gar nicht mit solchen Feinheiten wie Progressbars und ähnlichem auseinandersetzen. Außerdem kannst du mit dem Timer das Aktualisierungs-Intervall für die Anzeige komfortabel und unabhängig vom eigentlichen Thread regeln. Auch Dinge wie "Wenn die Anwendung minimiert ist brauche ich die Anzeige auch nicht zu aktualisieren" sind dort gut untergebracht. Packst du das alles in deinen Thread siehst du dort bald den Wald vor lauter Bäumen nicht mehr weil er sich nur noch zu 10% um seine eigentliche Aufgabe kümmert und der Rest mit eigentlich ganz anderem Anzeige-Kram vollgestopft ist.

[Jim Carrey]

Ok verstanden. Dazu muss ich was sagen, hatte ich vergessen!

Ich habe zwei Threads. Der eine macht die ganze Arbeit die zu erledigen ist und der zweite ließt die Variablen aus, welche im ersten gesetzt werden.
Und nur wenn der eventuelle neue Wert der ProgressBar größer ist als der alte, wird auch tatsächlich die GUI verändert.

Zitat:

"Wenn die Anwendung minimiert ist brauche ich die Anzeige auch nicht zu aktualisieren"

Würde ich verdammt gerne machen, geht momentan aber nicht, da ich nach dem Start der "Arbeit" eine while-Schleife habe die auf die Beendigung der Threads wartet.
Ich weiß, das ist harter Tobak und echt nicht schön aber leider noch ein Relikt aus früheren Zeiten meines Codes. Werde ich irgendwann mal abändern.

Edit:
ich sehe gerade dass ich sowas doch eingebaut habe. Aber ich prüfe nicht auf "bist du minimiert" sondern "bist du im Systembereich versteckt".

[Der schöne Günther]

Den zweiten Thread kann man sich dann echt sparen, der Teil wäre dann, wie gesagt, eigentlich doch in einem Timer super aufgehoben.

[stahli]

Oh, da habe ich eine andere Auffassung als der schöne Günther.
Ich haue die Meinung mal noch raus, mal sehen, wie das die Profis sehen...
(Der zweite Thread ist natürlich aus meiner Sicht dann auch überflüssig.)

---
Wenn Du in einer Timerbehandlung ständig MyThread.ProgressPosition ausliest und den Wert übernimmt, dann macht das der Timer ständig.
Er kann ja nicht wissen, ob es im Thread einen Fortschritt gab.
Er kann auch nicht wissen, ob der Thread gerade steht oder vielleicht schon terminiert ist.

Der Thread weiß viel besser, ob und wann eine Aktualisierung der Darstellung erforderlich ist. Und wenn der Thread fertig ist entfällt die Aktualisierung automatisch, ohne dass Du in einem Timer o.ä. noch etwas abschalten musst.

Also würde ich das im Synchronize belassen.
---

[Jim Carrey]

Was hätte der Timer denn dann für einen Vorteil gegenüber dem Thread?

Da oben mit der while-Schleife hab ich übrigens Quatsch geschrieben. Hab mir dem alten Code nochmal angesehen und funktioniert alles bestens mit "Wenn du mich nicht siehst, ändere mich auch nicht" (hat halt nur den Nachteil, dass man bei den Aero-Vorschaufenstern keine Änderung mehr wahrnimmt).

[Bambini]

Zitat:

Zitat von Jim Carrey (Beitrag 1351945)

geht momentan aber nicht, da ich nach dem Start der "Arbeit" eine while-Schleife habe die auf die Beendigung der Threads wartet.

wartet der Haupt-Thread auf das Ende vom Job-Thread in einer While Schleife, mit Sleep() und ProcessMessages()?.

[Bambini]

Zitat:

Zitat von Jim Carrey (Beitrag 1351950)

Was hätte der Timer denn dann für einen Vorteil gegenüber dem Thread?

Im Timer Event kann sich mit dem UI ohne Synchronize() unterhalten. Der Thread nicht.

[Jim Carrey]

Zitat:

wartet der Haupt-Thread auf das Ende vom Job-Thread in einer While Schleife, mit Sleep() und ProcessMessages()?.

Beides. Ich benutze eine gut angepasste Sleep-Version von negaH (so heißt er hier im Forum).

Zitat:

Im Timer Event kann sich mit dem UI ohne Synchronize() unterhalten. Der Thread nicht.

Bringt das auch Performance-Vorteile (weniger CPU-Last etc) wenn man das Synchronize() nicht mehr braucht?

[DeddyH]

Polling (und nichts anderes soll der Timer ja anscheinend tun) bringt wenn überhaupt nur selten Performancevorteile.

[Bambini]

Zitat:

Zitat von Jim Carrey (Beitrag 1351953)

Zitat:

Im Timer Event kann sich mit dem UI ohne Synchronize() unterhalten. Der Thread nicht.

Bringt das auch Performance-Vorteile (weniger CPU-Last etc) wenn man das Synchronize() nicht mehr braucht?

Ja, der Thread läuft immer. Der Timer nur, wenn er getriggert wird.
Man könnte es noch etwas optimieren, wenn der Thread den Timer erst einschaltet, wenn es auch eine Änderung gab.
Also im dem Stil:

Delphi-Quellcode:

TThread.Synchronize(nil, procedure () 
 begin
   MainForm.Progress      := Self.Progress;
   MainFrom.Timer.Enabled := True;
 end);

Der Timer triggert dann nach der Zeit und schaltet sich selbst erst einmal wieder ab.

[DeddyH]

Wie wäre es mit TThread.Queue?

[Jim Carrey]

Bevor ich mich Queue widme eine Verständnisfrage:
- muss ich auch das Ändern des Hints und das Ändern des Icons des Tray-Icons meiner Anwendung sychronisieren?
- muss ich auch einfaches "besorgen von Informationen" synchronisieren? Zum Beispiel das Besorgen der Caption eines Labels?

[Bambini]

Zitat:

Zitat von DeddyH (Beitrag 1351958)

Wie wäre es mit TThread.Queue?

Der Führt dann die Methode immer aus. D.h. bei jedem noch so kleinen Progress, wird die Methode gerufen.
Die Timer-Lösung macht ein Update nur einmal in der vorgegebenen Zeit, egal wie oft der Timer eingeschaltet wurde.
Das bringt ein wenig "Ruhe" rein ;-)

[Bambini]

Zitat:

Zitat von Jim Carrey (Beitrag 1351960)

Bevor ich mich Queue widme eine Verständnisfrage:
- muss ich auch das Ändern des Hints und das Ändern des Icons des Tray-Icons meiner Anwendung sychronisieren?
- muss ich auch einfaches "besorgen von Informationen" synchronisieren? Zum Beispiel das Besorgen der Caption eines Labels?

Ja und Ja.

[DeddyH]

Ich habe das Gefühl, ich verstehe die Problemstellung nicht richtig, oder andere haben ein eigenes Verständnis von Threads. Ich persönlich war zumindest noch nie in der Verlegenheit, einen Thread pollen zu müssen, das kommt mir so "von hinten durch die Brust ins Auge" vor.

[Der schöne Günther]

Und genau das ist der Punkt den ich meine. Siehst du wie aufwändig und fummelig das jetzt schon wird? Lass den Thread die eigentliche Arbeit machen, mach deine Oberflächen-Aktualisierungen in einem Timer und du bist schon fertig. 8-)

[ConnorMcLeod]

Mein Senf dazu:

Gib dem Arbeiterthread ein Event-Property.
Definiere im Form eine Aktualisierungsprozedur.
Weise diese Aktualisierungsprozedur dem Thread-Property zu.
Lass den Thread entscheiden, ob sein Zustand eine Aktualisierung rechtfertigt. Wenn ja, dann das Property (die Aktualisierungsprozedur) mittels Synchronize aufrufen.
In der Aktualisierungsprozedur prüfst Du, ob die Form sichtbar ist und machst die Aktualisierungen oder nicht.

Damit ist erreicht, daß dem Thread die Form nicht bekannt sein muß und es gibt eine klare Zuständigkeitstrennung.

[stahli]

Das halte ich auch für den richtigen Weg.

Allerdings würde ich mir den Aufwand mit einem Event ersparen und das Formular dem Thread direkt bekannt machen, sofern die Funktionalität nur in diesem einen Formular benötigt wird.

Aber mit Event ist es natürlich noch klarer voneinander entkoppelt.

[Jim Carrey]

Zitat:

Und genau das ist der Punkt den ich meine. Siehst du wie aufwändig und fummelig das jetzt schon wird?

Wieso aufwendig? In meinem Fall sind das circa 40 Zeilen Code die dafür sorgen, dass die GUI an den richtigen Stellen aktualisiert wird. Das ist doch nicht aufwendig :P
Der Thread hat mehrere Kriterien:

- while not Terminated
-- schlafe 25ms
-- berechne neue ProgressBar-Position
-- ist die Position größer als die alte UND ist mindestens Zeit X vergangen
--- JA > GUI aktualisieren

[Der schöne Günther]

Worauf ich hinaus wollte war nur:

Dein Thread wird ja wohl "echte" Arbeit tun und nicht einen Progressbar-Indicator hochsetzen. Der Thread sollte sich um ebendiese Arbeit kümmern. Immer wenn du an der Oberfläche was änderst musst du evtl. auch diesen Thread anpassen. In zwei Jahren besteht mindestens die Hälfte deines Threads aus Code für irgendwelche Feinheiten der Oberfläche während der Code für die eigentliche Arbeit immer weiter dahinter versumpft.

[Jim Carrey]

Genau, deswegen hab ich ja zwei Threads.
Ich wollte "Arbeit" von "GUI-Anpassung" trennen.

Vorher war es ungefähr so...

- Mach deine Arbeit Schritt 1
-- prüfe A
-- prüfe B
-- prüfe C
-- passe die GUI an
- Mach deine Arbeit Schritt 2
...
..

Und damit der Arbeiterthread nun seine Arbeit in Ruhe machen kann, hatte ich das vor ein paar Monaten getrennt.

Zitat:

In zwei Jahren besteht mindestens die Hälfte deines Threads aus Code für irgendwelche Feinheiten der Oberfläche während der Code für die eigentliche Arbeit immer weiter dahinter versumpft.

Ich verstehe solche Aussagen nie.
Warum sollte der Thread versumpfen? Wenn ich etwas an meinem Programm rändere, ändere ich auch überall das, was damit zusammenhängt. Da kann nix versumpfen :P

[stahli]

Ein Thread zwischen Arbeitsthread und Gui würde Sinn machen, wenn der Arbeitsthread irgendwelche Ergebnisse in einer Liste bereitstellt, die die Gui (oder ein anderer Thread) nach und nach abarbeiten muss.

Das ist ja aber vorliegend offenbar nicht notwendig.

Also würde ich nach den Zuständigkeiten schauen.

Der Arbeitsthread berechnet etwas und kann einen Fortschrittswert bereit stellen.

Die GUI dient der Darstellung und Bedienung durch den User.

Da der Thread ohnehin läuft und die Darstellung über Synchronize problemlos möglich ist, würde ich das dort veranlassen.

Im Formular kann der User sich - wenn er will - normal bewegen und etwas schreiben und so nebenbei ändert sich die Progressbar Stück für Stück.

Die GUI selbst muss nicht wissen, was der Thread tut oder wie weit er ist. Ein kleiner Teil der GUI-Funktionalität wird einfach vorübergehend vom Thread gesteuert.

Da braucht es m.E. keinen zweiten Thread und keinen Timer.



Anders wäre es (nur), wenn die Prozesse vollständig getrennt wären, also z.B. auf verschiedenen Rechnern im Netzwerk oder so.
Dann könnten der Arbeitsshread im Server und die GUI im Client natürlich nicht aufeinander zugreifen. Dann wäre im Client ein Timer oder Thread erforderlich, der die neuen Daten abfordert und zeichnet.
Das ist ja aber hier nicht gegeben.

Erkläre doch mal, warum Du nicht MyForm.ShowProgressValue(Value) synchronisiert aufrufen willst. Das ist doch die einfachste und sauberste Lösung (wobei es mit einem Event noch sauberer, aber etwas aufwendiger wäre).

[Luckie]

Also den Sinn eines zweiten Threads, um die GUI zu aktualisieren erschließt sich mir nicht so ganz. Und mit einem Timer zu guckcjen wie weit der Thread ist, ist auch etwas sinnbefreit.

Der Thread weiß doch am besten wie weit er ist. Also kann er auch der GUI seinen Fortschritt mitteilen (Synchronize, Events, Nachrichten). Wenn ich ein Paket erwarte gehe ich doch auchnicht alle fünf Minuten vor die Tür und gucke, ob der Paketbote vor der Tür steht. Dazu habe ich eine Türklingel (Event, Nachricht), die mir sagt, dass der Paketbote vor der Tür steht.

Hier gibt es nich ein etwas älteres Tutorial zu Threads von mir: http://michael-puff.de/Programmierung/Delphi/Tutorials/

[Jumpy]

Ist ein Timer nicht auch eigentlich ein Thread? Somit wäre es gleichwertig, ob ich per 2. Thread oder Timer den Fortschritt des 1. Thread "überwache".

Da ein Thread ja eher Teil der Business-Logik ist, ist es mMn gar nicht so verkehrt, dass der Arbeiter-Thread nicht selbstständig die GUI ändern kann. Auch sollte ein Thread nicht unbedingt selbst entscheiden können müssen, wann die GUI aktualisiert werden muss.

Insofern find ich eine Kombination aus der von ConnorMcLeod vorgeschlagenen Event-Property, plus einer Info wann diese feuern soll (z.B. alle 10% Fortschritt) die man dem Thread von Aussen mitgibt in diesem Fall sinnvoll. Dazu dann ruhig auch eine von Aussen abfragbare Property, die den aktuellen Fortschritt o.ä. ausgibt und schon ist man flexibel, wie man den Thread nutzen möchte.

[Jim Carrey]

Für mich stand damals im Vordergrund den Arbeiterthread zu entlasten.
Ich wollte Arbeit und Anzeige trennen was bis heute gut klappt.

Aber da ich irgendwo in diesem Forum mal gelesen habe, dass man dafür eigentlich einen Timer nimmt, dachte ich frage ich mal nach. Aber da gehen die Meinungen ja stark auseinander.

[Luckie]

Ein Timer ist kein Thread! Ein Timer wird durch Windows Nachrichten ausgelöst (WM_TIMER).

[stahli]

Die Timerbehandlung ist kein Thread.

Der Mainthread rödelt ständig in einem Loop und schaut, was zu tun ist.
Er prüft, ob Tastaturnachrichten anliegen und gibt diese an die Controls weiter.
Dann schaut er, ob OnIdle etwas zugewiesen ist und führt das aus, wenn sonst nichts zu tun ist.
Und er schaut, ob Timermessages anliegen.
Dann behandelt er diese, indem die zugewiesene Ereignisbehandlung ausgeführt wird.
Dauert diese 2 Minuten, hängt die GUI so lange.

Ob Du ShowProgressValue(Value) jetzt in einer Timer-Behandlung ausführst oder synchroniert aus dem Arbeitsthread aufrufst, nimmt sich für die GUI nicht viel.
Lediglich der Thread wird bei Synchronize-Nutzung in dem Moment für ein paar Millisekunden unterbrochen, bis der Mainthread die Änderung zulässt. Diese Änderung läuft dann genau so im Mainthread-Loop wie die oben skizzierte in einer Timerbehandlung.
Der Arbeitsthread sagt dann halt nur: Ich will mal eine Änderung veranlassen, sag mir, wenn ich kann... Ich warte mal so lange...

Bei jeder Lösung müssen beide Prozesse irgendwie aufeinander abgestimmt werden. Du musst entscheiden, welchen Aufwand Du betreiben willst und welche Performanceanforderungen Du hast.
Solang Deine Progressaktualisierung Dein Projekt nicht ausbremst würde ich die einfachste Lösung wählen.
Wenn das System ausgebremst wird (bei extrem vielen, extrem schnellen Änderungen) dann würde ich einfach nur jede 100. Änderung an die Gui geben und fertig.

Wenn Du vom Thread aus über Synchronize Deine Gui in Teilen aktualisierst heisst das nicht, dass Du Logik und GUI vermischt.

Man kann das noch klarer trennen, aber man sollte auch Aufwand und Nutzen abwägen.

[DeddyH]

Anscheinend bin ich doch nicht der Einzige, der dieses Timer-Geraffel nicht versteht, das beruhigt mich *puh*.

[Bambini]

Zitat:

Zitat von Luckie (Beitrag 1351981)

Wenn ich ein Paket erwarte gehe ich doch auchnicht alle fünf Minuten vor die Tür und gucke, ob der Paketbote vor der Tür steht. Dazu habe ich eine Türklingel (Event, Nachricht), die mir sagt, dass der Paketbote vor der Tür steht.

Aber es kann den den Hauptthread extrem nerven, wenn der Postbote jede Millisekunde an der Tür schellt, nur weil er gerade wieder ein 0,000001% Päckchen hat. Das mag ja ganz ganz nett sein, aber dann ist der Hauptthread doch wieder nur mit dem Postbosten beschäftigt. Daher hat die Lösung: Selbst und in regelmäßigen Zeiten an die Tür zu gehen und dann auf ein mal alle Päckchen rein zu holen, nicht schlecht.

[Jim Carrey]

Zitat:

Zitat von Luckie (Beitrag 1351984)

Ein Timer ist kein Thread! Ein Timer wird durch Windows Nachrichten ausgelöst (WM_TIMER).

Das ist mir vollkommen klar. Wenn du den Verlauf des Themas gelesen hättest wüstest du auch warum ich Timer und Threads in einen Topf werfe.

Zitat:

Zitat von stahli (Beitrag 1351985)

...

Vielen Dank für die ausführliche Antwort.

[DeddyH]

Dann sagt man dem Boten eben, dass er nur bei jedem vollen Prozent klingeln soll. Das ist doch keine Raketentechnik.

[Jim Carrey]

Zitat:

Daher hat die Lösung: Selbst und in regelmäßigen Zeiten an die Tür zu gehen und dann auf ein mal alle Päckchen rein zu holen, nicht schlecht.

Genau. Und das macht mein zweiter Thread nebenher immer, wenn die ausgerechneten Prozent der verarbeitung höher sind als die davor UND wenn eine gewisse Zeitspanne zutrifft.

[Bambini]

Zitat:

Zitat von DeddyH (Beitrag 1351989)

Dann sagt man dem Boten eben, dass er nur bei jedem vollen Prozent klingeln soll. Das ist doch keine Raketentechnik.

Nun, je nachdem, was da gerade für ein Paket in Arbeit ist (z.B. ein Download eine Delphi.ISO),
kann es bei einem riesigen Paket recht lange dauern, bis da 1% fertig sind und einer klingelt. Bis dahin sieht und hört man nix.

[DeddyH]

Und was genau würde ein Timer daran ändern?

[Bambini]

Zitat:

Zitat von DeddyH (Beitrag 1351993)

Und was genau würde ein Timer daran ändern?

Der sagt dir dann eben, dass da gerade erst mal 0,00001% erledigt sind.

[stahli]

Aber damit schießt Du mit Kanonen auf Spatzen. ;-)

Irgendwann kommst Du dazu, dass die Organisation der simplen Zwischennachricht aufwendiger wird als Deine Berechnung selbst.

Du kannst das natürlich so machen, aber es ist m.E. unnötig kompliziert und bietet keinen wirklichen Vorteil.

Hast Du denn irgendwie Hänger oder spürbare Verzögerungen, wenn Du aus dem Arbeitsthread einfach synchronisiert MyForm.ShowProgressValue(Value) aufrufst (ohne zweiten Thread und ohne Timer)?

Wenn ja, müsste man nach der Ursache schauen, aber dann stimmt irgendwo anders sicher etwas nicht.

Wie lange arbeitet der ArbeitsThread eigentlich und wie viele Zwischenschritte werden erledigt (also wie viele Progress-Aktualisierungen gibt es)?

[Jim Carrey]

Zitat:

Hast Du denn irgendwie Hänger oder spürbare Verzögerungen, wenn Du aus dem Arbeitsthread einfach synchronisiert MyForm.ShowProgressValue(Value) aufrufst (ohne zweiten Thread und ohne Timer)?

Falls du damit mich meinst: gefühlt war der Prozess langsamer, als es noch 1 Thread war.
Ich habe natürlich immer total übertrieben und direkt eine for-schleife 10.000 Mal dieselbe Arbeit machen lassen. Aber bei meiner Software ist Zahl 10.000 gar nichts.

Ich sehe das halt so... warum muss man dem Benutzer nach jedem Objekt der for-Schleife eine Änderung an der GUI mitteilen, wenn das auch alle 1000ms geht.
Und diese 1000ms kann ich in einem zweiten Thread wesentlich sauberer und besser berechnen als im Arbeiterthread.