3

我正在测试我的计算机体系结构的方式Interlocked.Increment和lock行为，因为我阅读了以下几行本文中的以下几行。

正如用 Interlocked.Increment 重写的那样，该方法应该执行得更快，至少在某些架构上是这样。

使用下面的代码，我确信在我的项目中检查锁是值得的。

var watch = new Stopwatch();
var locker = new object();
int counter = 0;

watch.Start();
for (int i = 0; i < 100000000; i++)
{
    lock (locker)
    {
        counter++;
    }
}
watch.Stop();
Console.WriteLine(watch.Elapsed.TotalSeconds);

watch.Reset();
counter = 0;

watch.Start();
for (int i = 0; i < 100000000; i++)
{
    Interlocked.Increment(ref counter);
}
watch.Stop();
Console.WriteLine(watch.Elapsed.TotalSeconds);

我得到了稳定的结果，锁定的近似值为2.4 秒，互锁的近似值为 1.2 秒。然而，我惊讶地发现在发布模式下运行此代码仅将 Interlocked 的值提高到大约0.7 秒，并且锁定时间保持不变。这是为什么？在没有锁的释放模式下如何优化互锁？

4

1 回答 1

5

您必须查看生成的机器代码才能看到差异，Debug + Windows + Disassembly。Interlocked.Increment() 调用的调试版本：

   00FC27AD  call        7327A810

发布构建版本：

   025F279D  lock inc    dword ptr [ebp-24h]

或者换句话说，抖动优化器在发布版本中变得非常聪明，并将对辅助函数的调用替换为单个机器指令。

优化并没有比这更好。相同的优化不能应用于lock语句下方的 Monitor.Enter() 方法调用，它是在 CLR 中实现的一个非常重要的函数，不能内联。除了 Interlocked.Increment() 之外，它还做了很多事情，它允许操作系统在线程阻塞尝试获取监视器并维护等待线程队列时重新调度。这对于确保良好的并发性非常重要，只是不在您的测试代码中，因为锁是完全没有争议的。谨防不接近实际使用情况的综合基准。

于 2013-12-22T16:22:15.880 回答