Honestly I'm not so sure about the case for spinning; in x264 source you can see CRITICAL_SECTION is tuned to have a spincount of 0. This is a very optimized, m

Honestly I'm not so sure about the case for spinning; in x264 source you can see CRITICAL_SECTION is tuned to have a spincount of 0. This is a very optimized, multi-threaded app. They didnt want any spinning. https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c14575d7d39eb8fadb97f/common/win32thread.c#L47 https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c1457... In my own attempts I've been unable to measure the impact of the spinlock count, and took spincount = 40 like in https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Lock.cpp?rev=200444#L44 https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/... ...who also took measurement from elsewhere. The default is 4000 on Windows! I don't argue spinning isn't valuable ; what I say is that it's necessarily never the bottleneck (else your task size really is too small). After all, if you spend all your time in synchronization, that means you probably need to have bigger tasks, not more clever synchronization primitives.