Question

今天我写了一些代码来测试互斥锁的性能。

这是boost（1.54）版本，在vs2010上使用O2优化编译：

boost::mutex m;
auto start = boost::chrono::system_clock::now();
for (size_t i = 0; i < 50000000; ++i) {
    boost::lock_guard<boost::mutex> lock(m);
}
auto end = boost::chrono::system_clock::now();
boost::chrono::duration<double> elapsed_seconds = end - start;
std::cout << elapsed_seconds.count() << std::endl;

这是在VS2013上编译的std版本，也有O2优化：

std::mutex m;
auto start = std::chrono::system_clock::now();
for (size_t i = 0; i < 50000000; ++i) {
    std::lock_guard<std::mutex> lock(m);
}
auto end = std::chrono::system_clock::now();
std::chrono::duration<double> elapsed_seconds = end - start;
std::cout << elapsed_seconds.count() << std::endl;

有点不同但做同样的事情。我的CPU是英特尔酷睿i7-2600K，我的操作系统是Windows 7 64位，结果是：0.7020s vs 2.1684s，3.08次。

boost :: mutex将首先尝试_interlockedbittestandset，如果它失败了，那么大奶酪WaitForSingleObject将排在第二位，它很容易理解。

似乎VS2013的std :: mutex要复杂得多，我已经知道了试图了解它，但我无法理解，为什么这么复杂？有更快的方法吗？

Answer 1

似乎stl::mutex可能只使用系统调用，这需要很多开销;但是boost::mutex以编程方式实现了至少一些功能 - 即尽可能避免系统调用，这是try _interlockedbittestandset之前WaitForSingleObject检查的原因。

我不知道MS的stl的实际内部结构，但我从操作系统类中的示例中看到了这样的性能差异。

Answer 2

测试仅测试锁定未锁定互斥锁的情况，而不会与其他线程产生任何争用。

让我们说互斥锁被锁定了。在初始加速尝试之后，线程旋转或阻塞会更好吗？这完全取决于应用程序。也许stl one在重负载下表现更好。

当时代需要高效的互斥锁时，实现相同目标的无锁替代方案值得探索。

为什么boost :: mutex比vs2013的std :: mutex更快？

2 个答案: