c - InitializeCriticalSectionAndSpinCount 最优 SpinCount(用户态)

Question

我不太了解 InitializeCriticalSectionAndSpinCount 的文档: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683476(v=vs.85).aspx

它说“您可以通过选择较小的旋转计数来显着提高性能......”

但是，由于等待微调器比等待对象更快，因此让 SpinCount 尽可能高不是很有意义吗？我错过了什么？谢谢。

(我在多线程应用程序使用的 C DLL 中使用它)

这是临界区的代码，被大量线程不断调用:

int g_slots[256] = {0};
...
slot = 256;
EnterCriticalSection(&g_LockHandle);
while (slot-- > 0)
{
    if (g_slots[slot] == 0)
    {
        g_slots[slot] = spid;
        break;
    }
}
LeaveCriticalSection(&g_LockHandle);

---

后续评论:

对于任何感兴趣的人，以下是我在运行 Windows 2008 R2 的 4 核服务器上进行测试时的非正式结果:如果执行超快操作(例如测试和递增单个变量)，Interlocked 无疑会胜出。遥遥领先的第二个是具有低旋转计数(例如 16)的 CriticalSection+SpinCount，其次是普通的旧 CriticalSection。但是，如果扫描一个数组(例如，整数)，Interlocked 排在第三位，仅次于 CriticalSection(有或没有 SpinCount)。 CriticalSection+high SpinCount 在所有情况下都是最慢的。

尼尔·韦彻 www.netlib.com

Answer 1

文档实际上说的是:

You can improve performance significantly by choosing a small spin count for a critical section of short duration.

因此，自旋计数的选择非常关键地取决于临界区的持续时间。

你问:

However, since waiting on a spinner is faster than waiting for an object, doesn't it make sense to have the SpinCount as high as possible?

旋转比阻塞快是不正确的。对于持续时间较长的临界区，最好避免完全自旋。如果很可能在很长一段时间内都不会释放锁，那么最好的策略是立即阻塞并等待您获得锁。即使是持续时间很短的部分，持有锁的线程也可能没有被安排运行，在这种情况下自旋显然会浪费 CPU 资源。

只有在自旋时很有可能获得锁时，自旋才有用。即便如此，只有当旋转所花费的时间少于屈服所花费的时间时，上下文切换成本才会增加。