In einer etwas umfangreicheren Anwendung soll im Hintergrund gelesen und die Datei-Inhalte ausgewertet werden, während man die bereits vorliegenden Ergebnisse vom Dateianfang schon bewundern kann.
Das Lesen und Auswerten ist in einen Thread gepackt, der nur wenige globale Variablen nach außen gibt und die Daten in Arrays füllt.
Die Darstellung außen liest aus den "vorn" liegenden Bereichen der Arrays aus, während der Thread "hinten" weiter füllt.
Klappt alles auch schön sauber. Wenn die Anwendung aber auf einer HT-Maschine laufen soll, dann bleibt der Thread regelmäßig hängen. Die CPU-Last klemmt bei 50% die Task liefert keine Rückmeldung mehr. In manchen Fällen läuft der "außen" eingebaute Timer weiter, beim nächsten Versuch unter scheinbar gleichen Bedingungen nicht. Die Zeitpunkte der Hänger sind ebenfalls mehr oder minder zufällig, aber nach 1 - 5 Sekunden ist meist Schluss.
Offenbar vergibt WinXP das Hauptprogramm als ersten Thread an die eine und den gestarteten Hintergrund-Thread an die andere "CPU" und dies führt zu den geschilderten Problemen.
Warum läuft die Sache nicht ?
Was muss man dabei besonders beachten ?
Gibt es Erfahrungen mit solchen Konstruktionen ?
Gibt es Statements der Entwickler dazu ?
HT, PB und Threads - kein gutes Trio ?
Re: HT, PB und Threads - kein gutes Trio ?
Dafür sind Multiprozessoren ja da, dass jeder Prozessor eine Sachejear hat geschrieben:Offenbar vergibt WinXP das Hauptprogramm als ersten Thread an die eine und den gestarteten Hintergrund-Thread an die andere "CPU" und dies führt zu den geschilderten Problemen.
Warum läuft die Sache nicht ?
Was muss man dabei besonders beachten ?
Gibt es Erfahrungen mit solchen Konstruktionen ?
Gibt es Statements der Entwickler dazu ?
erledigen kann.
Ich denke, die Sache läuft nicht, da der Thread auf einem single CPU
System Performance klaut, sodass die Zugriffe halbwegs hintereinander
weg passen. Auf deinem HT System werden die jedoch synchron
abgearbeitet, wodurch irgendwas nicht funktioniert. Du solltest mit jedem
PB Befehl vorsichtig sein, wenn in PB irgendwas Thread sicher ist, dann ist
das nicht Absicht
Habe aber eben getestet, Arrays scheinen threadsicher.
Da also im Zweifelsfalle von einer Critical Section (siehe einen Code von
Rings, glaube im alten Forum) gebrauch machen.
Das ist definitiv kein PB Bug
Lars
The only problem with troubleshooting is, that sometimes the trouble shoots back.
P4 2,6Ghz, 512MB RAM, GeForce 6200, WinXP Pro SP2, PB V3.94
The only problem with troubleshooting is, that sometimes the trouble shoots back.
P4 2,6Ghz, 512MB RAM, GeForce 6200, WinXP Pro SP2, PB V3.94
Vielen Dank für Eure Hilfe.
Nun blicken wir durch und kommen voran.
Die entscheidenden Kriterien für eine solche Konstruktion wie die unsere sind wohl :
- strenges Handshaking zwischen GUI und Hintergrundthread
- keine Stringbearbeitung im Thread
- wasserdichte Definitionen der Variablen
Da fehlt echt ein "option explicit" !
Nun blicken wir durch und kommen voran.
Die entscheidenden Kriterien für eine solche Konstruktion wie die unsere sind wohl :
- strenges Handshaking zwischen GUI und Hintergrundthread
- keine Stringbearbeitung im Thread
- wasserdichte Definitionen der Variablen
Da fehlt echt ein "option explicit" !