Sleep(1)
-
Hey!
Was bringt eigentlich Sleep(1) genau? Sehe das schon überall. Wenn ich das einbaue, braucht mein Programm 0.00% Prozessorleistung laut process explorer. Das Programm macht fast nichts, aber es bleibt wirklich dauernd auf 0 und der PC rennt so schnell wie sonst.
Ansonsten braucht mein Programm 100%...
-
Sleep sorgt dafür, dass das Program für eine bestimmte Zeit keine CPU-Ressourcen zugeteilt bekommt.
-
Aha, das bedeutet dann also wirklich, dass mein Programm den Prozessor nur minimal auslastet?
-
Ja, weil es ja nichts macht...
-
Sleep verwende ich gerne wenn ich über 10 werte berechnen und anzeigen lasse, d.h. ich verlangsame die berechnung und ermögliche somit die verfolgung der rechenschritte durch den benutzter
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum WinAPI verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Sleep schrieb:
Was bringt eigentlich Sleep(1) genau? Sehe das schon überall.
Wundert mich auch, dass das immer noch verwendet wird. Wenn es um Prozessorauslastung geht, reicht Sleep(0) doch vollkommen aus.
-
groovemaster schrieb:
Sleep schrieb:
Was bringt eigentlich Sleep(1) genau? Sehe das schon überall.
Wundert mich auch, dass das immer noch verwendet wird. Wenn es um Prozessorauslastung geht, reicht Sleep(0) doch vollkommen aus.
Sleep(0) => Prozessorauslastung wird nicht reduziert (Thread wird *nicht* schlafen gelegt)
Sleep(1) => Thread wird für min. 10-15 ms schlafen gelegt
-
Jochen Kalmbach schrieb:
Sleep(0) => Prozessorauslastung wird nicht reduziert (Thread wird *nicht* schlafen gelegt)
Sleep(0) sorgt dafür, dass der aktuelle Thread seine restliche Prozessorzeit abgibt. Und das reicht vollkommen aus. Man muss den Thread nicht extra schlafen legen.
-
verzichtet einfach komplett auf diese sleep scheisse. es gibt immer eine bessere lösung.
-
Als da wäre?
Du kommst jedenfalls um Sleep bzw. SwitchToThread nicht herum, wenn du einen nicht-blockierenden Message Loop benötigst und nicht gleichzeitig mit 100% Auslastung andere Prozesse blockieren willst.
-
ewoi schrieb:
verzichtet einfach komplett auf diese sleep scheisse. es gibt immer eine bessere lösung.
Nein.
(außer vielleicht SleepEx)
-
Kann man das nicht alles mit Timern machen?
-
groovemaster schrieb:
Als da wäre?
Du kommst jedenfalls um Sleep bzw. SwitchToThread nicht herum, wenn du einen nicht-blockierenden Message Loop benötigst und nicht gleichzeitig mit 100% Auslastung andere Prozesse blockieren willst.
Das war wohl so bei Windows 3.x. Für zeitintensive Aufgaben verwendet man heutzutage Workerthreads und Events. Andere Prozesse werden normalerweise nur blockiert bei falscher Verwendung von SetPriorityClass oder SetThreadPriority. Eine Message-loop benötigt keine Sleep-Anweisung, das System legt Deinen Process automatisch schlafen, wenn keine Messages anliegen.
-
groovemaster schrieb:
Jochen Kalmbach schrieb:
Sleep(0) => Prozessorauslastung wird nicht reduziert (Thread wird *nicht* schlafen gelegt)
Sleep(0) sorgt dafür, dass der aktuelle Thread seine restliche Prozessorzeit abgibt. Und das reicht vollkommen aus. Man muss den Thread nicht extra schlafen legen.
Naja, dass ist nur die halbe Wahrheit... die restliche Prozessorzeit wird nur abgegeben, wenn es einen anderen Thread gibt, der laufen will!
Somit bleibt aber hier die Prozessorlast immer auf "Vollast" (zumindest für einen Prozessor).
-
Naja, dass ist nur die halbe Wahrheit... die restliche Prozessorzeit wird nur abgegeben, wenn es einen anderen Thread gibt, der laufen will!
Somit bleibt aber hier die Prozessorlast immer auf "Vollast" (zumindest für einen Prozessor).Soweit ich weiss gibt Sleep(0) auch immer nur an threads mit gleicher (oder höherer) Priorität ab. Wenn es einen "runnable" thread gibt der aber eine niedrigere Priorität hat wird der keine Rechenzeit bekommen.
Sleep(0) reicht daher NICHT und ist BÖSE.p.S.: Sleep(1) wartet auch nicht unbedingt >= 10ms, obwohl man mit einem Delay von 10-20ms rechnen sollte, ggf. viel mehr, und auf otto-normal-system es ~15ms sein werden.
-
_mgs schrieb:
Das war wohl so bei Windows 3.x...
Nö, das ist heute immer noch so. Eine nicht-blockierende Nachrichtenschleife ohne Sleep(0), SwitchToThread, WaitMessage oder was auch immer, hat einen Prozess mit 100% CPU-Auslastung zur Folge. Natürlich friert das System dadurch nicht ein, wie es unter Win3.x teilweise der Fall war. Es werden trotzdem andere Prozesse dadurch eingebremst.
Jochen Kalmbach schrieb:
Naja, dass ist nur die halbe Wahrheit... die restliche Prozessorzeit wird nur abgegeben, wenn es einen anderen Thread gibt, der laufen will!
Somit bleibt aber hier die Prozessorlast immer auf "Vollast" (zumindest für einen Prozessor).Ein Prozessor hat _immer_ "Last". Es ist nur die Frage, ob der Prozessor durch Threads ausgelastet wird oder nicht. Und wenn nicht, sich dann in den "Leerlauf" begeben kann. Ich bin mir zwar nicht ganz sicher, aber ich glaube Energiesparfunktionen, wie zB CnQ von AMD, werden damit entsprechend geregelt. Und Sleep(0) reicht jedenfalls aus, um die CPU Zeit mindestens an den Leerlauf abzugeben. Es ist daher auch irrelevant, ob es einen anderen User Thread gibt, der laufen will.
hustbaer schrieb:
Soweit ich weiss gibt Sleep(0) auch immer nur an threads mit gleicher (oder höherer) Priorität ab. Wenn es einen "runnable" thread gibt der aber eine niedrigere Priorität hat wird der keine Rechenzeit bekommen.
Was ebenfalls irrelevant ist. Sleep(0) gibt nicht an "irgendjemanden" ab. Sleep(0) sagt dem System lediglich, dass der aktuelle Thread seine verbleibende CPU Zeit nicht mehr benötigt und anderweitig verwendet werden kann. Und wenn das System irgendwann feststellt, dass ein Thread mit niedrigerer Priorität an der Reihe ist, dann wird es diesen auch ausführen. Egal ob irgendwo Sleep(0) verwendet wurde oder nicht.
hustbaer schrieb:
Sleep(0) reicht daher NICHT und ist BÖSE.
Nö, Sleep(0) ist nicht böse. Böse ist, einen uninitialisierten Zeiger zu dereferenzieren. Oder mit goto rückwärts zu springen. Sleep(0) ist, wenn überhaupt, dann in bestimmten Situationen uU nicht ausreichend.
-
Eine nicht-blockierende Nachrichtenschleife ohne Sleep(0), SwitchToThread, WaitMessage oder was auch immer, hat einen Prozess mit 100% CPU-Auslastung zur Folge. Natürlich friert das System dadurch nicht ein, wie es unter Win3.x teilweise der Fall war. Es werden trotzdem andere Prozesse dadurch eingebremst.
Das ist schlichtweg falsch. Eine Standardwarteschleife a la
MSG msg; while( GetMessage( &msg, NULL, 0, 0 ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); }
erzeugt keine nennenswerte Prozessorlast. Aus der Doku zu GetMessage:
"Unlike GetMessage, the PeekMessage function does not wait for a message to be posted before returning."
Wie Du siehst, kommt GetMessage erst zurück, wenn eine neue Nachricht für Dein Programm vorliegt - vorher tut sich gar nichts.
Wenn Du es nicht glaubst, schreib einfach ein kleines Programm mit dieser Messageloop und überprüfe die Prozessorlast.
-
Nö, Sleep(0) ist nicht böse.
Sleep ist vielleicht nicht böse - aber die häufige Verwendung dieser Funktion deutet zumindest auf Faulheit oder mangelnde Kenntnisse beim Programmieren hin. Sleep wird gerne eingesetzt, wenn Threads Ergebnisse pollen sollen und der Programmierer sich an Signalisierungsobjekte und Wartefunktionen nicht herantraut.
Wer Threads und Signale sinnvoll einsetzt, benötigt kein Sleep.
-
_mgs schrieb:
Das ist schlichtweg falsch.
Nö, ist es nicht. Dein Beispiel hat keine nicht-blockierende Nachrichtenschleife, denn wie du schon selbst festgestellt hast, geht es im Thread erst weiter, wenn eine Nachricht vorliegt. Nicht-blockierend bedeutet natürlich eine Schleife mit PeekMessage.
_mgs schrieb:
Sleep ist vielleicht nicht böse - aber die häufige Verwendung dieser Funktion deutet zumindest auf Faulheit oder mangelnde Kenntnisse beim Programmieren hin. Sleep wird gerne eingesetzt, wenn Threads Ergebnisse pollen sollen und der Programmierer sich an Signalisierungsobjekte und Wartefunktionen nicht herantraut.
Darum geht es überhaupt nicht. Für Multithreading sollte man natürlich auf sinnvolle Signalisierungsobjekte zurückgreifen. Hier ging es ausschliesslich um Sleep und die damit verbundene CPU Last des jeweiligen Threads. Und Sleep(1) macht nunmal keinen Sinn, wenn es einem einzig und allein um den Effekt von Sleep(0) geht.