Ich führe eine Berechnung in einem Thread aus, die ein außerhalb des Thread definiertes Array bearbeitet, und zwar so: Ist eine Teil-Berechnung fertig, rufe ich in der OnTerminate-Ereignisprozedur des Thread eine Prozedur im Hauptthread auf, die
1. Die berechneten Daten aus dem Array auswertet und in eine Datei speichert
2. den gleichen Thread mit neuen Berechnungsparametern erneut startet
wodurch sich ein Berechnungskreislauf ergibt, so dass die Anwendung ständig beschäftigt ist.
Es passiert nun nach einigen Stunden fehlerfreien Ablaufs, dass das Programm ohne Fehlermeldung stehenbleibt, anscheinend, weil die max. von Windows verwaltbare Threadanzahl überschritten wurde. Es lässt sich jedenfalls in diesem Zustand keine andere Anwendung mehr starten.
Jetzt habe ich von m_junglas im Thema "Programmabsturz! Warum?" gelernt, dass der Thread nach OnTerminate keineswegs schon beendet ist und man keinen Einfluss darauf hat, wann Windows nun gedenkt, ihn wirklich zu beenden. Dass das wirklich so ist, sieht man auch, wenn man in der OnTerminate-Ereignisprozedur "WaitFor" verwendet - Das Programm steht dann ab da und wartet quasi auf sich selbst. Wenn das also so ist, ist OnTerminate für mich unbrauchbar, denn ich will ja den Thread quasi aus der OnTerminate-Ereignisprozedur heraus neu starten (eigentlich ein Wunder, dass das Programm erst nach Stunden, d.h. nach einigen Tausend Berechnungs-Zyklen, stehenbleibt). Also hier beißt sich die Katze in den Schwanz, denn in der OnTerminate-Ereignisprozedur darf ich den Thread auch nicht beenden, wie schon m_junglas feststellte, andererseits will ich den Hauptthread auch nicht ständig prüfen lassen, ob der Thread noch läuft, so ähnlich wie NicoDE im Thema "Unit in Thread packen?!" vorschlug...:

while not CalculationTerminated do Application.ProcessMessages(); // Solange die GUI reagieren lassen

...denn ich brauche den Prozessor ja für die Berechnung.

Ich brauche also, im Gegensatz zu OnTerminate, das Ereignis, wann der Thread WIRKLICH von Windows beendet wurde. Delphi erkennt das ja anscheinend auch, wie man im Debugfenster "Threads" sehen kann.
Weiß einer, wie man's macht?

Zusatzfrage: Wie ändere ich eigentlich die Priorität des Haupt-Thread einer Anwendung?

Moin engel,

Zitat von engel:

andererseits will ich den Hauptthread auch nicht ständig prüfen lassen, ob der Thread noch läuft,
...
...denn ich brauche den Prozessor ja für die Berechnung.

Ja und? Wenn Du Nicos Verschlag folgst funktioniert das doch...

While BerechnungOffen do begin
Thread erstellen
Thread mit Daten füttern
Thread starten, und auf Ende warten.
Thread freigeben.
end;

Zitat von engel:

Delphi erkennt das ja anscheinend auch, wie man im Debugfenster "Threads" sehen kann.

und wer sagt, dass das an einem Ereignis liegt, und nicht genauso gemacht wird, wie oben beschrieben?


[EDIT]

Zitat von engel:

wann der Thread WIRKLICH von Windows beendet wurde.

Ich will mal schwer hoffen, dass ein Thread nicht von Windows beendet wird, dass könnte dann eigentlich nur durch TerminateThread erfolgen, was einem "Abschiessen" des Threads gleichkommt, also nicht gerade empfehlenswert ist.
[/EDIT]

Zitat:

Ja und? Wenn Du Nicos Verschlag folgst funktioniert das doch...

Ich behaupte ja auch nicht, dass es nicht funkt', sondern dass es meine Berechnung verlangsamt
Es muss doch was Besseres geben.

Wieso erstellst Du einen Thread jedesmal neu?

Schreibe dir einen 'Workerthread', der im Hintergrund auf Jobs wartet. Sobald ein Job ankommt, wird er bearbeitet und anschließend geht das Spiel von vorne los. Falls zwischenzeitlich ein neuer Job angekommen ist, wird der gleich verarbeitet. So ist das sauber.

Und ein Job ist einfach eine Teilaufgabe. Ich vermute, das Du im OnTerminate den Thread nicht einfach neu anstoßen kannst. Vielleicht kommt Windows da durcheinander.

Hi,

So sollte es mit weniger CPU last gehen:

zusammenfalten · markieren

Delphi-Quellcode:

    
     While BerechnungOffen do
     begin
       //Thread erstellen
       //Thread mit Daten füttern
       repeat
         dwWaitResult := WaitforSingleObject(Thread.Handle, 200);
         if dwWaitResult <> WAIT_OBJECT_0 then
         begin
           Application.ProcessMessages;
         end;
       until dwWaitResult = WAIT_OBJECT_0;
       //Thread freigeben
     end

Hierbei dient BerechnungOffen nur zum Beenden der gesammten Berechnung.
Du wirst ohne eine Steuerung auserhalb des Arbeitenden Threads nicht auskommen.

Edit : oder so wie alzaimar es vorgeschlagen hat mit Jobs dafür giebts hier auch irgendwo einen Code.

Zitat von alzaimar:

Wieso erstellst Du einen Thread jedesmal neu?

Schreibe dir einen 'Workerthread', der im Hintergrund auf Jobs wartet. Sobald ein Job ankommt, wird er bearbeitet und anschließend geht das Spiel von vorne los. Falls zwischenzeitlich ein neuer Job angekommen ist, wird der gleich verarbeitet. So ist das sauber.

Und ein Job ist einfach eine Teilaufgabe. Ich vermute, das Du im OnTerminate den Thread nicht einfach neu anstoßen kannst. Vielleicht kommt Windows da durcheinander.

Hört sich gut an! Leider keinen blassen Schimmer, wie man einen Thread auf Job's warten lässt.
Was ich weiß ist, dass die Execute-Methode des Threads nur einmal ausgeführt werden kann (oder stimmt das nicht?). Dann müsste die Execute-Methode ja eine Endlosschleife enthalten? Wie programmiert man dieses "auf einen Job warten"?
Oder kann man FreeOnTerminate auf False setzen und den Thread etwa mehrmals hintereinander mit Resume starten?

Hi,
Schau mal hier(letzter Post):
Thread and Jobs

Ich hoffe das hilft dir.

Zitat:

Schau mal hier(letzter Post):
Thread and Jobs

Danke, das mit den Job's probier ich mal aus.

Aber die Lösung meines Problems ist einfach nur: In der OnTerminate-Ereignisprozedur den Thread auf NIL setzen (sonst nix)!

Matthias