My experience on Windows:
YieldProcessor() -- same as _mm_pause etc, just an energy efficient NOP. Great for hyperthreaded CPUs or ones with energy efficiency modes!
SwitchToThread() -- politely give up your timeslice to another thread that's ready to use your core right now. Does not consider threads queued up on other cores.
Sleep(0) -- Will switch to any thread that isn't of lower priority than yours. If no other threads are ready, you'll at least go for a run through the OS scheduler for a moment.
Sleep(1) -- really truely give up your core at least for a whole timeslice.
My busy-wait functionality tries each of these an arbitrary number of times in this order, but also checks a "task queue" in between each attempt to sleep/stall, to see if I can use the thread for something useful instead of sleeping/stalling.
@Idov, what's the reason behind needing to stall a thread for such a short period in the first place?
I've always been told that windows is not a RT system and it can't wait for periods shorter than 1 ms... Is it wrong?
...accuracy of the sleep instruction, which is pretty pathetic (16ms last time I checked).
Windows provides timeBeginPeriod/timeEndPeriod to change the scheduling quantum. By default it's 15ms IIRC, but a lot of "realtime" apps use these functions to change it to 1ms (which yes, is the lowest it can be set to). This is a system-wide setting though, and decreasing the quantum can have a negative effect across the whole system in exchange for making it a little bit more real-time-ish.
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 )
Edited by Hodgman, 19 May 2013 - 03:34 AM.