Betriebssystem: Windows 7
Wenn die WinAPI Sleep () -Funktion als Sleep (1) aufgerufen wird, wird der Thread tatsächlich für 15 ms gespeichert. Ich habe es 100 Mal in einer Schleife gemacht und die gesamte Schlafzeit war 1500ms statt 100.
Ist das gängige Verhalten, oder sollte ich mich damit befassen, dass etwas mit meiner MOBO-, CPU- und Windows-Installation nicht stimmt?
EDIT: Wenn möglich könnten Sie diesen Code ausführen und posten, wie lange die Ruhezeit war. Ich ließ einen Freund von mir das laufen, und er hatte wirklich alles bei 1ms.
%Vor%EDIT2: Es scheint, dass der Grund, warum einige Leute 1ms bekommen, dass ein anderes Programm läuft, das die systemweite Timerauflösung auf 1ms setzt. Standardmäßig sollte dies bei Windows 7 15.6ms sein.
Ist das übliche Verhalten
?
Es ist.
Der Thread-Scheduler von Windows arbeitet mit einem Zeitquantum (die genaue Länge hängt von verschiedenen Faktoren ab, einschließlich Windows-Version und -Edition). Effektiv wird jede Nicht-Null-Verzögerung auf ein vollständiges Quantum aufgerundet.
Sleep kann dazu führen, dass der Thread länger als das angegebene Zeitlimit schläft, es garantiert nur, dass der Thread für mindestens diese Zeit inaktiv bleibt.
Aus der Dokumentation :
Nachdem das Schlafintervall abgelaufen ist, kann der Thread ausgeführt werden. Wenn Sie 0 Millisekunden angeben, gibt der Thread den Rest seiner Zeitscheibe ab, bleibt jedoch bereit. Beachten Sie, dass ein fertiger Thread nicht garantiert sofort ausgeführt werden kann. Daher wird der Thread möglicherweise erst einige Zeit nach Ablauf des Ruhezustands ausgeführt. Weitere Informationen finden Sie unter Planung von Prioritäten .
Die besten Artikel, die ich bezüglich des Timings unter Windows gefunden habe, sind hier und hier . Der nützliche Teil ist, dass Sie die Multimedia-Timer-Auflösung ändern (zB timeBeginPeriod (1) für 1ms) betrifft auch den Sleep-Befehl, da er den Scheduler im Allgemeinen betrifft. Dies bedeutet, dass eine Genauigkeit von 1 ms bei einem Nicht-Echtzeit-Betriebssystem nicht möglich ist.
Sie sollten die Timer-Auflösung Ihres Geräts überprüfen. Siehe die msdn-Dokumentation von Sleep () für Details.
Dies ist ein ziemlich normales Verhalten, da die meisten Uhrauflösungen 10-15 ms betragen. Wenn Sie es daher mit einem Wert aufrufen, der kleiner als die Taktauflösung ist (in Ihrem Fall 1), muss es wahrscheinlich mindestens einen Taktzyklus warten, weshalb es länger schläft als Sie möchten.
Im Allgemeinen sollten Sie Sleep nicht für Dinge verwenden, die aufgrund dieser Probleme eine solche Genauigkeit erfordern.
Das Verhalten ist OK. Zugrunde liegende Hardware, Version des Betriebssystems und sogar laufende Software beeinflussen die Angewohnheit des Betriebssystems in Bezug auf die Funktion sleep ().
Wenn ein Sleep mit dwMilliseconds aufgerufen wird, der kleiner ist als die Systeminterruptzeit, wird der Aufruf beim nächsten Interrupt zurückgegeben. Auf diese Weise hängt die tatsächliche Verzögerung von der Zeit ab, zu der der Schlafmodus aufgerufen wurde (in Bezug auf die Unterbrechungszeit).
Es wird empfohlen, die Multimedia-Timer-Schnittstelle zu verwenden, um die Interrupt-Frequenz auf das von der Hardware unterstützte Maximum zu erhöhen, wenn ein Sleep (1) gewünscht wird.
Eine detaillierte Übersicht über die Funktionen sleep (), waitable timer, timer resolutions und multimedia timer settings finden Sie im Windows Timestamp-Projekt
(debuggen oder veröffentlichen Build?)
Wie messen Sie die Verzögerung? Benutzt du eine genaue Methode? (queryperformancecounter)
Ich denke nicht, dass Sie sich für ein genaues Timing auf das Windows-Betriebssystem verlassen sollten. Es ist kein Echtzeit-Betriebssystem, und es wird externe "Kräfte" geben, die Ihrem Prozess Zeit entziehen.