Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   100 % CPU Last durch Thread (https://www.delphipraxis.net/29251-100-cpu-last-durch-thread.html)

Luckie 16. Mär 2014 16:45

AW: 100 % CPU Last durch Thread
 
Warum innerhalb eines Threads Application.ProcessMessages; ?

d7user1 16. Mär 2014 17:11

AW: 100 % CPU Last durch Thread
 
ohne Application.ProcessMessages in der Sleep-Methode blockt meine anwendung. warum weiß ich nicht. <- quatsch.

habe die procedure nun so geändert dass über eine boolsche variable geprüft wird ob man ProcessMessages braucht oder nicht.
wenn der aufruf aus einem thread kommt > nein, sonst > ja.

bisher gibt es aber keinen unterschied bezüglich cpu last.

mjustin 16. Mär 2014 17:29

AW: 100 % CPU Last durch Thread
 
Zitat:

Zitat von d7user1 (Beitrag 1252156)
ich pausiere das mit einem
Delphi-Quellcode:
while pausiert do LongDelay(25);
.
die prozessorauslastung bleibt aber konstant auf dem vorherigen wert und sinkt nicht auf 0.

Was spricht denn dagegen einfach ein Sleep(25) zu verwenden? In einem Thread, der momentan mangels Aufgabe in einem 'Pause' Zustand ist, wird ein Sleep(25) keine negativen Auswirkungen auf die Programmausführung haben, auch nicht für den VCL Thread.

d7user1 16. Mär 2014 17:36

AW: 100 % CPU Last durch Thread
 
also ein sleep(25) funktioniert im thread. aber im vcl-thread blockt es mir das ganze programm.

jaenicke 16. Mär 2014 18:00

AW: 100 % CPU Last durch Thread
 
Wenn du eine Single Core CPU hast und dein Thread viel zu tun hat, spricht aber auch gar nichts dagegen, dass der 100% CPU Last erzeugt. Warum sollte die Aufgabe des Threads denn auch unnötig lange brauchen?

Im Process Explorer kannst du auch schauen welcher Thread überhaupt die Auslastung verursacht.

mjustin 16. Mär 2014 18:36

AW: 100 % CPU Last durch Thread
 
Zitat:

Zitat von d7user1 (Beitrag 1252173)
also ein sleep(25) funktioniert im thread. aber im vcl-thread blockt es mir das ganze programm.

Sleep im VCL-Thread blockiert natürlich das Programm. Aber worauf bzw. warum soll denn im VCL-Thread 25 Millisekunden gewartet werden? Wie sieht die Warte-Funktion (LongDelay) jetzt aus?

himitsu 16. Mär 2014 19:28

AW: 100 % CPU Last durch Thread
 
Wenn im Hauptthread nichts gemacht wird (also keine Messages anstehen),
dann ist diese Schleife ständig nur mit Nachsehen beschäftigt, ob es jetzt was gibt und lastet dann mit Nichts den Kern/Thread zu 100% aus.

PS: Selbst ein Sleep(0) kann etwas ausrichten.
Jeder Thread bekommt ja bom Sheduler immer paar Millisekunden zum Arbeiten, bis die anderen Threads auch mal etwas Zeit bekommen. Und Sleep(0) gibt die Restzeit sofort ans Windows zurück.

OlafSt 16. Mär 2014 21:11

AW: 100 % CPU Last durch Thread
 
Wenn ich mir die Execute-Methode da ansehe (von den bösen Zugriffen auf die VCL abgesehen), wundert mich da nichts.

Würde man die Execute-Methode in den Mainthread verlagern und so laufen lassen, wäre die CPU-Last 100%. Warum sollte das also in einem Thread anders sein ? Es ist ein Trugschluß zu glauben, man verlagere seinen Programmcode einfach in einen Thread und *poff*, geht meine CPU-Last auf Null ;)

Ein volles Rohr in einer Endlosschleife laufendes Programm belegt eben auch die komplette Zeit die CPU - egal ob nun im Mainthread oder als Nebenthread. Erst, wenn Pausen ins Spiel kommen (zum Beispiel "nur alle 250ms eine Runde durchs TreeView"), geht die Last auch zurück.

jaenicke 16. Mär 2014 21:21

AW: 100 % CPU Last durch Thread
 
Zitat:

Zitat von OlafSt (Beitrag 1252185)
Wenn ich mir die Execute-Methode da ansehe

Nicht verwechseln. d7user1 ist nicht der Fragesteller von damals.
Aber solche Missverständnisse sind vorprogrammiert, wenn man einen alten Thread kapert statt einen eigenen aufzumachen. ;-)


Alle Zeitangaben in WEZ +1. Es ist jetzt 02:07 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz