问题描述

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

I don't quite understand the documentation for InitializeCriticalSectionAndSpinCount: http://msdn.microsoft/en-us/library/windows/desktop/ms683476(v=vs.85).aspx

上面写着您可以通过选择较小的旋转次数来显着提高性能......"

It says "You can improve performance significantly by choosing a small spin count ..."

然而，因为等待一个微调器比等待一个对象要快，所以让 SpinCount 尽可能高是不是有意义?我错过了什么?谢谢.

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? What am I missing? Thanks.

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

(I am using it inside a C DLL used by a multi-threaded application)

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

Here is the code for the critical section, called constantly by a large number of threads:

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);

<小时>

后续评论:

Followup comments:

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

For anyone that is interested, here are my informal results when testing on a 4 core server running Windows 2008 R2: if doing an ultra-fast operation such as test and increment a single variable, Interlocked wins hands down. A distant second is CriticalSection+SpinCount with a low spin count (e.g., 16), followed by plain old CriticalSection. However, if scanning an array (e.g., of integers), Interlocked comes in third, after CriticalSection (with or without SpinCount). CriticalSection+high SpinCount was the slowest in all cases.

尼尔·韦彻wwwlib

推荐答案

文档实际上说的是:

您可以通过为短持续时间的关键部分选择较小的旋转次数来显着提高性能.

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

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

So, the choice of spin count depends very critically on the duration of the critical section.

你问:

然而，由于等待一个微调器比等待一个对象要快，所以让 SpinCount 尽可能高是不是有意义?

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 资源.

It is simply not true that spinning is faster than blocking. For a long duration critical section, it is best to avoid spinning altogether. If it is likely that the lock won't be released for a significant amount of time, then the best policy is to block immediately and wait until you can acquire the lock. Even for a short duration section, it is possible that the thread that holds the lock is not scheduled to run, in which case spinning is clearly wasteful of CPU resource.

自旋只有在很有可能在自旋时获得锁的情况下才有用.即便如此，只有当旋转所花费的时间小于屈服所花费的时间时，上下文切换成本才会发生.

Spinning is only beneficial if there is a good probability that the lock can be acquired whilst spinning. And even then only if the time spent spinning is less than the time spent yielding, the context switch cost.

这篇关于InitializeCriticalSectionAndSpinCount 最佳 SpinCount(用户模式)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！