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

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是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至少以編程方式實現了它的一些功能 - 即它盡可能避免系統調用，這就是在WaitForSingleObject之前檢查try _interlockedbittestandset的原因。

我不知道MS的stl的實際內部結構，但是我從操作系統類的例子中看到了這樣的性能差異。

Answer 2

該測試僅測試鎖定未鎖定互斥鎖的條件，而不會與其他線程產生任何爭用。

假設互斥鎖被鎖定了。 在初始加速嘗試之后，線程旋轉或阻塞會更好嗎？ 這完全取決於應用程序。 也許stl one在重負載下表現更好。

當時代需要高效的互斥鎖時，實現相同目標的無鎖替代方案值得探索。