Yeah they haveI'd like to point out that nobody has asked why the OP would like to inject a 0.2ms pause in his application.
Looks like he's trying to make a sampling profiler:
I'm trying to sample another process (memory, stack, etc) and I'm checking the boundaries of what I can and cannot do (without using all the resources of the computer).
I guess I missed that. When I wrote my profiler, I found that firing at 3ms intervals off a system timer was more than enough, and in fact you could bring down the sampling rate significantly if you were dealing with fairly repetitive processes like games tend to have. Actually my take on that is that it will cost you far more time to freeze your target's threads and walk the stacks than it will to deal with these little timing quirks.
Off topic: IIRC, there's also a rule in the scheduler where if a thread has been starved for 5 seconds, it will be boosted to the highest priority to ensure it gets at least 1 slice around once per 5 seconds (which is a very weak guarantee compared to what actual RT OS's give you
)
There's another such feature, which actually gives a quite good almost-RT behaviour (awesome in theory, in practice not always so) when using waitable timers as proposed by frob. When a waitable object becomes signalled, a thread waiting on it gets its priority temporarily boosted (presumably for 1 time slice, though the docs don't state for how long).
The Windows scheduler serves threads from highest priority downwards, serving higher priority threads until none is left, and also interrupts lower priority threads before their time slice has been used up when higher priority threads become ready.
That is, in theory (if nobody has tampered with process priorities, and no disk I/O thread is busy) this ensures that the thread actually runs "immediately" when the timer fires. Even though it doesn't always work quite as good as intended, in any case it's a not-totally-stupid approach that works more often than it doesn't, and it makes using waitable timers as good as you can get.
I think the original solution that the OP mentioned will also have the negative impacts that have been discussed throughout this thread. If he sits in a loop spinning and checking the time elapsed, the thread could be pre-empted immediately before he reaches the desired elapsed time. That would put his granularity at the mercy of the scheduler too, so I think the many good suggestions that have been given will provide equal precision to what he is currently using...
With that said, has the OP tried doing a series of NOP in his loop that he is checking the elapsed time in? That would allow you to change the granularity of your checking, and reduce the power consumption of the loop at the same time.
