I'm not sure in *nix systems, but in windows you can use sleep(x);, x are the ms, including windows.h: #include <Windows.h>
If you explain a little more what you want to do... because the if( delay() ) {} doesn't look good at first sight :)
neithan
Junior Poster in Training
92 posts since Oct 2009
Reputation Points: 12
Solved Threads: 3
Skill Endorsements: 0
windows.h SetTimer(). Your program must be Windows (WinMain instead of main) and have a message pump for that to work.
If you just want a console program then you could create a thread and call Sleep() in a loop to put that thread to sleep then execute some code when it wakes up
Ancient Dragon
Achieved Level 70
32,144 posts since Aug 2005
Reputation Points: 5,836
Solved Threads: 2,577
Skill Endorsements: 69
The "delay" function is called Sleep() and you can get it through the <windows.h> header. The Sleep function sleeps for the specified number of milliseconds. However, do not expect good precision, thread-switching frequency in Windows is notoriously slow and unresponsive, don't expect precision higher than about 10ms to 30ms.
The other solution is to use the clock() function in a tight loop. As so:
#include <ctime>
void delay_us(std::clock_t us_interval) {
std::clock_t end_time = clock() + (us_interval * CLOCKS_PER_SEC) / 1000000;
while( clock() < end_time ) ;
};
mike_2000_17
21st Century Viking
3,140 posts since Jul 2010
Reputation Points: 2,062
Solved Threads: 625
Skill Endorsements: 41
while( clock() < end_time ) ;
Sorry, but that's a horrible suggestion as it consumes all the cpu time leaving little or mnothing for other windows programs.
Ancient Dragon
Achieved Level 70
32,144 posts since Aug 2005
Reputation Points: 5,836
Solved Threads: 2,577
Skill Endorsements: 69
Sorry, but that's a horrible suggestion as it consumes all the cpu time leaving little or mnothing for other windows programs.
Yes you are correct, it is horrible, but the operating systems doesn't give you a choice if you want to sleep for a time-interval below 10ms or so, because that is basically the resolution of the Sleep function. Using timers can get you closer to a few millisecond resolution for a nearly-constant refresh rate (or frame rate) on calling a call-back function. For anything below that, as the OP is asking, your only choice is to have a tight loop (and possibly with an atomic lock if you can) because as soon as you use a Sleep or timer function you have to relinquish thread time to the thread scheduler with a software-level wake-up interrupt which has a minimum latency of at least a few milliseconds. For precise timing operations (down to tens of kilo-hertz resolution, i.e., 100 to 10 micro-seconds), you need a hard-real-time system, and Windows is not designed for that at all.
mike_2000_17
21st Century Viking
3,140 posts since Jul 2010
Reputation Points: 2,062
Solved Threads: 625
Skill Endorsements: 41
and Windows is not designed for that at all.
Yup, and neither is *nix. That was one of the nice things about MS-DOS. There are add ons to MS-Windows, such as this one, that provide accurate millisecond response time, but I think they cost lots of $$$.
Ancient Dragon
Achieved Level 70
32,144 posts since Aug 2005
Reputation Points: 5,836
Solved Threads: 2,577
Skill Endorsements: 69
Yup, and neither is *nix.
That's true for most *nix variants (at least, desktop / server operating systems), but remember that *nix variants is a very wide family, and almost all real-time operating systems are *nix variants, like QNX, LynxOS, VxWorks, FreeRTOS, and certain special versions of Linux (e.g., RTLinux). There are some slap-on frameworks for doing hard-real-time on Windows, but they effectively shutdown Windows kernel activity and replace it with their own kernel, which is often a posix-compliant micro-kernel. And yes, those cost quite a bit of money, because they usually involve strict quality and determinism guarantees.
But again, to make it clear, all my points about latencies and wait times on Windows apply, for the most part, exactly the same for all other generic desktop operating systems. Server versions have the same problem, but I think they are faster (software interrupts are clocked faster). And, of course, the actual latency / response times will vary between the different operating systems. But I know that desktop Linux versions (at least, those I have worked with, Ubuntu, Red Hat and SUSE) are clocked to achieve sub-millisecond resolution on sleeping / timing / wake-ups, since I have run up to 4 kHz multi-threaded apps (with thread synchros) on Linux kernels, so, in my experience, the resolution is at least down to the 100 to 50 micro-second range. But, of course, the same problems apply (not hard-real-time systems), but at one or two orders of magnitude higher time-resolution.
mike_2000_17
21st Century Viking
3,140 posts since Jul 2010
Reputation Points: 2,062
Solved Threads: 625
Skill Endorsements: 41
There is no such standard win32 api functon. Sleep() is not even constant on the same CPU let along all CPUs because there are many other programs running and competing for CPU time. Sometimes programs do something that cannot be interrupted. If you need exact millisecond timing then don't use MS-Windows.
Ancient Dragon
Achieved Level 70
32,144 posts since Aug 2005
Reputation Points: 5,836
Solved Threads: 2,577
Skill Endorsements: 69
Milton Neal
Junior Poster in Training
59 posts since Sep 2010
Reputation Points: 10
Solved Threads: 13
Skill Endorsements: 0
Would this result in hogging the CPU too?
Yes, it has the same affect as Mike's previous post. It would be ok if you would put a Sleep(1) somewhere in that loop -- but don't expect the program to be asleep for only 1 millisecond, most likely it will not wake up for about 10 milliseconds.
Ancient Dragon
Achieved Level 70
32,144 posts since Aug 2005
Reputation Points: 5,836
Solved Threads: 2,577
Skill Endorsements: 69