3 ms·

I believe the supposed beneficial case of blocking vs spinning can't be captured well by those categories, as it's "contended, but not for long" and "contended,

by ketzu 7y ago

I believe the supposed beneficial case of blocking vs spinning can't be captured well by those categories, as it's "contended, but not for long" and "contended, but for longer". That's the reason for the "may have a bit of capped spinning before waiting in the scheduler".

p0nce 7y ago
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.