views:

149

answers:

4

I there any method to sleep the thread upto 100.8564 millisecond under window OS. I am using multimedia timer but its resolution is minimum 1 second. Kindly guide me so that I can handle the fractional part of the milisecond.

+5  A: 

Yes you can do it. See QueryPerformanceCounter() to read accurate time, and make a busy loop.

This will enable you to make waits with up to 10 nanosecond resolution, however, if thread scheduler decides to steal control from you at the moment of the cycle end, it will, and there's nothing you can do about it except assigning your process realtime priority.

You may also have a look at this: http://msdn.microsoft.com/en-us/library/ms838340(WinEmbedded.5).aspx

Several frameworks were developed to do hard realtime on windows.

Otherwise, your question probably implies that you might be doing something wrong. There're numerous mechanisms to trick around ever needing precise delays, such as using proper bus drivers (in case of hardware/IO, or respective DMAs if you are designing a driver), and more.

Please tell us what exactly are you building.

Pavel Radzivilovsky
Actually I am developing real time application, and there is no chance to ignore even the fractional part of millisecond, its cause very damage at the end of output.
Arman
@Arman This much I have guessed :) what application? What is it supposed to to? Why output timing is so important? Is it important Every Time, or an error in certain percentage of time is OKay? Because if not, what I wrote might depend on other things in the system, including UI, some UI processes (like taskman) can have RP, kernel mode code can interfere, etc. What EXACTLY is your mission?
Pavel Radzivilovsky
If sub-millisecond jitter can cause physical damage, then I would strongly suggest that you use dedicated hardware (based on an MCU or FPGA) to control that output. You could also incorporate a watchdog timer and other safety interlocks into that output control board. Use the Windows machine for higher-level control only. Or go with a real-time OS on a platform where you have access to a high-resolution timer and can write your own interrupt service routine.
Emile Cormier
Emile Cormier
+3  A: 

I do not know your use case, but even a high end realtime operating system would be hard pressed to achieve less 100ns jitter on timings.

In most cases I found you do not need that precision in reproducibility but only for long time drift. In that respect it is relatively straightforward to keep a timeline and calculate the event on the desired precision. Then use that timeline to synchronize the events which may be off even by 10's of ms. As long as these errors do not add up, I found I got adequate performance.

Peter Tillemans
+2  A: 

The resolution of a multimedia timer is much better than one second. It can go down to 1 millisecond when you call timeBeginPeriod(1) first. The timer will automatically adjust its interval for the next call when the callback is delivered late. Which is inevitable on a multi-tasking operating system, there is always some kind of kernel thread with a higher priority than yours that will delay the callback.

While it will work pretty well on average, worst case latency is in the order of hundreds of milliseconds. Clearly, your requirements cannot be met by Windows by a long shot. You'll need some kind of microcontroller to supply that kind of execution guarantee.

Hans Passant
+3  A: 

If you need guaranteed latency, you cannot get it with MS Windows. It's not a realtime operating system. It might swap in another thread or process at an importune instant. You might get a cache miss. When I did a robot controller a while back, I used an OS called On Time RTOS 32. It has an MS Windows API emulation layer. You can use it with Visual Studio. You'll need something like that.

Jive Dadson