I have a polling loop in C# that needs to poll every 100 microseconds on average < EDIT> (given of course that there is no excessive preemptive thread context switch carried out by Windows due to core shortage) < /EDIT>.
As there is no time for a reschedule, Sleep(1) will not do.
So I decided to dedicate a thread (and in practise, a core when setting affinity) and use a Thread.SpinWait for a set of cycles for each iteration. While this works fine, it eats an unnecessary amount of power. The 100 microseconds would be plenty enough for the CPU to pause (while not enough to have the thread temporary removed from the scheduler as the Windows time-slice would be way to long).
Instead, I was thinking of using the Intel PAUSE instruction but I'm not sure it will trigger the Intel CPU to suspend the hardware thread. Intel claims it preserves power and should be used in a spin loop, but as the pause is as long a as 100 microsecond, I really want the core to go into a C1 mode sleep.
Any ideas?
Edit: I'm polling a third party API, so there is no synchronization event to block on.
Naturally using synchronization primitives and timers is a preferred way to go to avoid CPU/power-hungry busy wait. However, if you need to poll so frequently - there's no way to achieve this by conventional means, at least in user mode.
One simple thing that you may do is to include a pause CPU instruction within your loop. In MSVC it's implemented by an intrinsic YieldProcessor() method.
Beyond this - probably in kernel-mode programming only. There you may use a high-precision multimedia timer.
Edit:
About SetWaitableTimer. This may be an option. Unlike "traditional" Win32 waiting functions (such as Sleep, WaitForSingleObject and etc.) it uses a high-precision timeout as a parameter.
However user-mode timers are asynchronous in nature. Let's assume the timer becomes active with high precision (thpigh this is not obvious, "traditional" Win32 waiting functions are accurate up to tick quanta, order of tens of milliseconds). After the timer becomes active - it releases the appropriate waiting thread(s). But thread scheduler doesn't have to attach this thread to the execution immediately - it may wait for the next time slice. Or even delay the thread execution more if there are concurrent threads.
In conclusion: the idea seems worth trying. But I won't be surprised if this is more-or-less equivalent to using Sleep.