I already found out with another question that Windows/MingW doesn't provide the nanosleep() and setitimer() alternatives to the obsolete usleep(). But my goal is to fix all warnings that cppcheck gives me, including the usleep() style warnings.
So, is there a workaround to somehow avoid usleep() on Windows without using cygwin or installing loads of new dependencies/libraries? Thanks.
usleep() works with microseconds. In windows for getting microsecond precesion you should use QueryPerformanceCounter() winapi function. Here you can find how get that precesion using it.
I used this code from (originally from here):
#include <windows.h>
void usleep(__int64 usec)
{
HANDLE timer;
LARGE_INTEGER ft;
ft.QuadPart = -(10*usec); // Convert to 100 nanosecond interval, negative value indicates relative time
timer = CreateWaitableTimer(NULL, TRUE, NULL);
SetWaitableTimer(timer, &ft, 0, NULL, NULL, 0);
WaitForSingleObject(timer, INFINITE);
CloseHandle(timer);
}
Note that SetWaitableTimer() uses "100 nanosecond intervals ... Positive values indicate absolute time. ... Negative values indicate relative time." and that "The actual timer accuracy depends on the capability of your hardware."
If you have a C++11 compiler then you can use this portable version:
#include <chrono>
#include <thread>
...
std::this_thread::sleep_for(std::chrono::microseconds(usec));
Kudos to Howard Hinnant who designed the amazing <chrono> library (and whose answer below deserves more love.)
If you don't have C++11, but you have boost, then you can do this instead:
#include <boost/thread/thread.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
...
boost::this_thread::sleep(boost::posix_time::microseconds(usec));
ms user defined literal, as in std::this_thread::sleep_for(100ms);. This only works on constant values (obviously), and requires a using directive. See this answer for details. –
Indihar std::this_thread::sleep_for will use ::nanosleep when supported, but ::Sleep on Windows with millisecond resolution. Don't know about VS one. –
Frolicsome WaitForSingleObject cause the process to yield it's time slice and thereby cause a context switch? If so, the function is pretty much guaranteed to never wait accurately, as per design. –
Centrum usleep implementation has 16 ms accuracy / granularity, exactly the same as regular Sleep() –
Untruthful New answer for an old question:
Rationale for the new answer: Tools / OSs have been updated such that there is a better choice now than there was when the question was originally asked.
The C++11 <chrono> and <thread> std headers have been in the VS toolset for several years now. Using these headers this is best coded in C++11 as:
std::this_thread::sleep_for(std::chrono::microseconds(123));
I'm using microseconds only as an example duration. You can use whatever duration happens to be convenient:
std::this_thread::sleep_for(std::chrono::minutes(2));
With C++14 and some using directives, this can be written a little bit more compactly:
using namespace std::literals;
std::this_thread::sleep_for(2min);
or:
std::this_thread::sleep_for(123us);
This definitely works on VS-2013 (modulo the chrono-literals). I'm unsure about earlier versions of VS.
The millisecond regime of the Sleep() function is well described and well understood. It does not do anything unpredictable. Sometimes the function is blamed to perform unpredictable, i.e. returning before the delay has expired. I need to say that this is wrong. Careful investigation will confirm that its behaviour is absolutely predictable. The only problem is
that there is plenty to read about it and most of it is kiddish. It is also often said that
windows it not a real-time OS. But such comments don't contribute anything, moreover such
comments are used to hide the lack of knowledge. It makes me sort of angry, that not even
microsoft notices this and provides better documentation.
However, without exaggerating this little answer: The sleep() function is precise, when used in a proper way and when knowing its characteristics. Particular attention has to be given to sleep(0). This is a very powerfull tool, particulary when used together with process priority class, thread priority, multimedia timer settings, and processor affinity mask.
So generally a true sleep can be performed easely and safe down to the systems interrupt period. When it comes to sleeps shorter than the interrupt period spinning is required.
A higher resolution time source has to be used in oder to spin for shorter periods in time.
The most common source for this is the performance counter. QueryPerformanceCounter(*arg) delivers an incrementing *arg. QueryPerformanceFrequency(*arg) delivers the frequency at which the performance counter increments. This is typically in the MHz regime and varies, depending on the underlying hardware. A frequency in the MHz range provides microsecond resolution. This way something of high resolution can be used to wait for a desired time span to expire. However, the accuracy of this has to be looked at carefully: The OS returns the performance counter frequency as a constant. This is wrong! Since the frequency is generated be a physical device, there is always an offset and it also not a
constant. It has thermal drift. More modern systems do have less drift. But if the thermal drift is just 1ppm, the error will be 1us/s. The offset can easely be several 100. An offset of 100 in 1MHz corresponds to 100us/s.
If a thread shall wait for any time at high resolution, it shall establish a service thread. Both thread shall share a named event. The service thread shall sleep until 1 interrupt period ahead of the desired sleep delay and then spin on the performance counter for the remaining microsecond. When the service thread reaches the final time, it set the named event and ends. The calling thread will wake up, because it was waiting for the named event by means of a wait function.
Summary:
More detailed information can be found at the Windows Timestamp Project
constant_tsc. –
Beefcake constant. Reporting the CPU clock frequency in 1Hz units is somewhat stupid. Even units of 10 are ridiculous because the real frequency deviates by several ppm. 1ppm equals 2000Hz on a 2GHz hardware. So a more realistic granularity for the output of QPF should/could be 1ppm of the frequency. BTW: This would give people also the hint that the output of QPF is only an estimate. –
Manatee constant TSC would return QPF() with CPU freq./1024. The CPU freq. does not exist by hardware, it is gernerated by a frequency multiplier (1024). –
Manatee It depends what granularity you need. If you are talking milliseconds, then the Win32 Sleep function will do the job - see http://msdn.microsoft.com/en-us/library/ms686298%28v=vs.85%29.aspx. If you are talking microseconds, then there is no easy way to do it, and you would be lucky to get that sort of timer resolution on Windows (which is not an RTOS), or on Linux, come to that.
I found this blog post about it. It uses QueryPerformanceCounter. The function posted:
#include <windows.h>
void uSleep(int waitTime) {
__int64 time1 = 0, time2 = 0, freq = 0;
QueryPerformanceCounter((LARGE_INTEGER *) &time1);
QueryPerformanceFrequency((LARGE_INTEGER *)&freq);
do {
QueryPerformanceCounter((LARGE_INTEGER *) &time2);
} while((time2-time1) < waitTime);
}
I hope this helps a bit.
freq. Instead, if waitTime is given in microseconds, the final test should be time2-time1 < waitTime*freq/1000000 . –
Paquito _mm_pause() inside the loop. –
Untruthful I'm quite late to the party but I want just to add something to this question. If you want to achieve portability using microseconds resolution than use select() system call using empty file descriptor set. It will work both on linux and on windows, i.e. it can be called using an uniform interface (the behavior can be still different especially on Windows where you can ask for 1 microsecond but you get 1ms sleep). If you want to use a third-party library use Boost, but a recent version. The time related std api are just a mess and I provide a summary here:
So if you want portable code make your own solution or just use Boost 1.67+, don't trust standard implementation c++11 chrono because the implementation performed is really bad.
usleep() works with microseconds. In windows for getting microsecond precesion you should use QueryPerformanceCounter() winapi function. Here you can find how get that precesion using it.
© 2022 - 2024 — McMap. All rights reserved.
usleepfor? – Elwin