Hmm lots to look through there ?
It looks as though the problem is that intel has increased the number of cycles the CPU pause instruction pauses for.
I have yet to get my head around all the different ways that a thread can gain exclusive access to a system resourse because you can have spin locks, push locks, mutexes, semaphores and more but the pause problem seems to affect spin locks.
As i understand it if a thread manages to aquire a spinlock on a resourse and another thread requires it then the second thread will not enter a wait on event state thus releasing its CPU but instead it will enter a fixed length loop (spin) before trying again. We are now tying up 2 CPU cores with one doing nothing useful.
If im right the loop includes a pause instruction so a longer pause means that the second thread now spends longer spinning before checking to see if the resourse is free.
The aquire spinlock function used in .NET apps appears to make this worse by lncreasing the length of the loop every time it goes round.
All of the above could be wrong ?
If there is never any contention because there are only a few threads then the problem never happens.
.
