We're using Monitor.Enter to protect a shared data structure and we're seeing high CPU on a 24-core box. A profile shows that most threads are spinning waiting for a lock. No thread is doing extensive work while holding the lock and everyone eventually acquires the lock after the spin wait.
Spinning is great, if done in moderation, but what we're seeing is that the spinning is dominating the CPU, preventing real work from getting done thus freeing the lock.
Digging into the sscli20 code (yeah, ancient, but it's what we have) we found this comment in AwareLock::Contention (sscli20\clr\src\vm\syncblk.cpp):
// Delay by approximately 2*i clock cycles (Pentium III).
// This is brittle code - future processors may of course execute this
// faster or slower, and future code generators may eliminate the loop altogether.
// The precise value of the delay is not critical, however, and I can't think
// of a better way that isn't machine-dependent.
And the while condition that determines how long to spin is:
while (i < 20000*g_SystemInfo.dwNumberOfProcessors);
A couple questions:
1) Is that algorithm still accurate or have modern high-core-count machines been factored in? My guess is that it's the same given our observations.
2) Is there any way to control the spin count? I don't see anything in the sscli20 code, but maybe something was added later.