c++ - 为什么 boost::mutex 比 std::mutex 快于 vs2013？

Question

今天写了一些代码来测试mutex的性能。

这是 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 上编译，也有 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 是 Intel Core i7-2600K，我的操作系统是 Windows 7 64bit，结果是: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 的实际内部结构，但我从操作系统类的示例中看到了这样的性能差异。