What we do with the spin lock classes that we use in our products is a SwitchToThread call: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686352(v

What we do with the spin lock classes that we use in our products is a SwitchToThread call: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686352(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... If the SwitchToThread call returns False, then the code reverts to a Sleep(0) call instead. Credit to StackOverflow and Joe Duffy's excellent article on this: https://stackoverflow.com/questions/1383943/switchtothread-vs-sleep1 https://stackoverflow.com/questions/1383943/switchtothread-v... http://joeduffyblog.com/2006/08/22/priorityinduced-starvation-why-sleep1-is-better-than-sleep0-and-the-windows-balance-set-manager/ http://joeduffyblog.com/2006/08/22/priorityinduced-starvatio... However, as mentioned in one of the SO replies, you still need to make sure that you don't use locks that use loops on calls like this when those locks will have to wait on anything long-running - you're just going to burn CPU/battery needlessly. So, only use such locks when you know that the protected code doesn't involve any long wait states, or modify the code to back out even further into a proper kernel wait after looping X times. Personally, I agree with second SO answer and don't like such constructs, and would personally say just go with a straight-up kernel wait if there's any question about whether such conditions could exist now or in the future.