?
junix schrieb:
Kann es sein, dass deine Aufräumaktion relativ lang dauert?
Nein, die Aufräumarbeiten beschränken sich auf:
if (FDirectoryHandle != NULL && FDirectoryHandle != INVALID_HANDLE_VALUE)
CloseHandle(FDirectoryHandle);
delete[] fInfo;
und ähnliche einfache Operationen.
Und das Event wird erst ausgelöst, nachdem dies geschehen ist. Praktisch als letzte Funktion im Thread. Dennoch geht die CPU-Last für mehrere Sekunden auf 100%, wenn ich sofort danach, WaitFor() aufrufe. Setze ich ein Sleep(50) davor ist alles ok, die WaitFor-Funktion kehrt dann sofort zurück, ohne CPU-Last zu erzeugen. Alle Threads laufen allerdings mit Priority = tpLowest, weil die Anwendung nur wenig CPU-Zeit verbrauchen darf. Die läuft später auf Servern, die praktisch permanent am Anchlag laufen. Ich hätte mich durchaus mit 40 Sekunden zum Beenden der Anwedung abfinden können, wenn nur die CPU-Last nicht so dermaßen ansteigen würde.
junix schrieb:
Du könntest das Resultat von WaitForMultipleObjects auswerten und den auslösenden Thread entsprechend gleich killen. Dann hast du wieder etwas Parallelarbeit.
Das ist ja der Witz daran, das ist überhaupt nicht mehr nötig. So wie es jetzt ist, werden die Threads, beim Beenden der Anwendung, verzögerungsfrei gelöscht.
Das Problem scheint zu sein, dass man WaitFor() (oder auch delete IrgendeinThread) nicht sofort aufrufen darf, nachdem der Thread seine Execute-Methode abgeschlossen hat, sondern eine minimale Verzögerung einbauen muß. Es ist wohl wie Du schon gesagt hast, schlampig implemtiert...
Das WaitForMulti... wartet tatsächlich auf die Rückmeldung aller Threads, bevor es weitergeht. Dadurch, dass ich den Thread, der am längsten zur Rückmeldung braucht (der speichert noch was ab), als letzten mit WaitFor() auswerte, liegt bei allen Threads eien minimale Verzögerung zwischen ihrer Beendigung und dem WaitFor().
junix schrieb:
Schön, wenn jemand die nicht pfannenfertigen Lösungen auch mal positiv auffasst (o;
So was nenn ich 'Aus der Not eine Tugend machen'.
Das ganze ist mittlerweile auch ein bißchen komplexer geworden, als hier dargestellt. Nach diesen dummen Problemen die ich hatte, habe ich das Anwendungsdesign komplett umgestellt und die Arbeiten auf diverse Threads aufgedröselt, um zu prüfen, ob irgendeine Teilarbeit das Problem verursacht...
Die Hauptanwendung besteht praktisch nur noch aus dem Frontend und kommuniziert ausschließlich mit dem 'Controller' getauften Thread. Dieser wiederum ist für die Koordination der restlichen Threads zuständig. Ein Thread ist nur für die Überwachung der Verzeichnisse zuständig. Er schreibt die Namen der geänderten Dateien in ein Interface-Objekt.Dann meldet er die Änderung an den Controller (hier läßt sich hervorragend ein Semaphore-Objekt einsetzen ). Der Controller liest die Dateinamen aus dem Interface und stellt sie in die interne Warteschlange. Sobald sich was in der Warteschlange befindet, wird ein 'LogReader'-Thread erzeugt, der die Datei auswertet. Die Ergebnisse stellt er in ein Interface-Objekt. Seioe Execute-Methode wird abgeschlossen und er sendet das entsprechende Event an den Controller. Der holt die Ergebnisse aus dem Interface und stellt sie in das Interface für den 'ResultCollector'. Dann löst der Controller diesmal ein Semaphore aus und der ResultCollector liest die Daten aus dem Interfache, sortiert diese ein und lädt die geänderten oder neuen Datensätze stündlich auf einen FTP-Server hoch. Dort landen die Daten von 3 Servern... Bis auf den FTP-Teil ist es soweit funktionsfähig.
Es ist eigentlich ein Witz, welchen Aufwand ich hier betrieben habe, nur um dann festzustellen, das es gar nicht an mir lag...
Nun gut, jetzt bleibt es so, es läuft seht gut, so wie es jetzt ist und auch wenn man den Controller, den LogReader und den Resultcollector wieder zusammenfassen könnte.