programm hängt bei hoher CPU-Last

[thomas-io]

Hallo zusammen,

ich habe ein grössere Applikation (4 * IOW40) mit Delphi 7.0 unter WinXP entwickelt.
Ursprünglich eingesetzt die DLL, Version 1.4

Problem 1: Wenn einer (oder mehrere) der IOW's abgehängt werden bekomme ich bei IowKitReadNonBlocking keine Fehler, die Funktion liefert einfach "Müll" zurück
Problem 2: Bei IowKitCloseDevice() hängt sich die Applikation auf, spare ich mir den Close am Ende terminiert das Programm nicht richtig und ich muss mit Taskkill o.ä. die Reste abschiessen.

Dann habe ich die Version 1.5 eingesetzt: Problem 1 + 2 sind behoben, wenn jedoch auf dem Rechner die CPU-Last durch ein anderes Programm "hochgeht" (lässt sich einwandfrei durch den Calculator provozieren: 999999 eingeben und n! drücken) hängt sich die Applikation auf. Auch der Start von Excel etc. reicht oft aus damit die App hängt.

Wer hat einen guten Tipp ? Entweder mit der 1.4 die Probleme 1.+2. lösen oder das hängen bei der 1.5 vermeiden...

Danke und Gruss
Thomas

[Christoph Jung]

Für die 1.4 DLL liefern wir keinen direkten Support mehr, da diese durch die 1.5 abgelöst wurde. Also am besten auf die 1.5 DLL umsteigen.

Ein paar mehr Infos wären ganz hilfreich.
Wie schnell ist die CPU?
Was macht das Programm mit den IO-Warrior? Wie oft werden diese gelesen oder geschreiben? Wie schnell ist der Timer / Thread in dem das alles schieht.


Zu Problem 1.
Wenn man wären des Betriebes einen IO-Warrior abklemmt ist es ganz klar, dass ReadNoneBlocking "Müll" liefert. So etwas muss man in seinem Programm selber abfangen, in dem man die Eingehenden Reports auswertet und darauf dann reagiert. Sowas händelt die DLL nicht damit es keine Probleme gibt und man die vollständige Kontrolle hat.

Zu Problem 2.
Die Applikation dürfte sich nicht aufhängen, es sei denn es werden noch Read oder Write Befehle ausgeführt. Ohne ein CloseDevice() wird die DLL nicht entladen und blelbt somit Aktiv. Daher muss man diese dann auch über den Taskmanager abschießen. Um das CloseDevice kommt man also nicht herrum. Evtl hilft exit(1) der WinAPI aber lieber CloseDevice nutzen.

Wenn ein Programm viel CPU-Zeit benötigt, wie z.B. der Start von Exel, ein Virenscanner oder ein Spiel kann es durchaus vorkommen, dass das eigenen Prgramm "anstehen" muss um weiter ausgeführt zu werden. Das passiert allerdings nur wenn man sehr schnelle Operationen durchführt oder einen doch sehr betagten Prozessor am laufen hat. Wenn das Programm dann hängenbleibt liegt das in den meisten Fällen daran, dass solche Fälle nicht berücksichtigt wurden. Dazu kann man Try...catch... verwenden oder andere Mechanismen.
Man kann aber auch dem Prozess selber einen höhere Wertigkeit geben um solche Probleme zu umgehen ist aber nicht die feine englische Art.

[thomas-io]

Hallo,

schon mal Danke für das Feedback.

Da in meinem Programm knapp 10 Timer wühlen und das Zusammenspiel mit den 4 IOWs doch recht komplex ist habe ich mich darangemacht das Problem mit einem simpleren Programm nachzubauen.

Dabei ist mir aufgefallen das alle Beispielprogramme die ich mir angesehen habe mit ReadNonBlocking arbeiten und ich in meinem Grossprogramm ReadImmediate verwende. Zusätzlich habe ich noch ein paar Code-Zombies in einer "alten" unit gefunden die auch versucht haben die IOW's zu lesen.......
Ich habe das Modul dann umgebaut und voila: Keine Hänger mehr bei hoher Last. Das eigentliche Programm zieht ca. 1-2 % CPU-Last auf eine Core2Duo 2,4, ich kann die Last auf dem System bis 100% hochzwiebeln und das IO-Controlprogramm läuft noch.

Wenn man erst mal genau erklären muss was schiefgeht findet man oft selber den Fehler.

Aber: Bei ReadImmediate habe ich solange die IOWs dran waren immer ein schickes TRUE bekommen, wurden einer (oder mehr) abgesteckt kam sofort ein FALSE und ich konnte den Fehler abfangen bevor ich angefangen habe irgendwelchen Müll auzuwerten.

Hier würde mir jetzt noch ein Tipp weiterhelfen: Wie kann ich elegant abfangen wenn ein IOW "verschwindet"?

Danke und Gruss
Thomas