std::mutex 的性能与 CRITICAL_SECTION 相比如何？是否符合标准？

我需要轻量级同步对象(不需要是进程间对象)除了 std::mutex 之外，是否有任何接近 CRITICAL_SECTION 的 STL 类？

最佳答案

请在答案末尾查看我的更新，自 Visual Studio 2015 以来情况发生了巨大变化。原始答案如下。

我做了一个非常简单的测试，根据我的测量结果，std::mutex 比 CRITICAL_SECTION 慢了大约 50-70 倍。

std::mutex:       18140574us
CRITICAL_SECTION: 296874us

编辑:经过更多测试，结果表明它取决于线程数(拥塞)和 CPU 内核数。一般情况下，std::mutex 比较慢，但是多少，要看使用情况。以下是更新的测试结果(在配备 Core i5-4258U、Windows 10、Bootcamp 的 MacBook Pro 上测试):

Iterations: 1000000
Thread count: 1
std::mutex:       78132us
CRITICAL_SECTION: 31252us
Thread count: 2
std::mutex:       687538us
CRITICAL_SECTION: 140648us
Thread count: 4
std::mutex:       1031277us
CRITICAL_SECTION: 703180us
Thread count: 8
std::mutex:       86779418us
CRITICAL_SECTION: 1634123us
Thread count: 16
std::mutex:       172916124us
CRITICAL_SECTION: 3390895us

以下是产生此输出的代码。使用 Visual Studio 2012 编译，默认项目设置，Win32 发布配置。请注意，这个测试可能并不完全正确，但它让我在将代码从使用 CRITICAL_SECTION 切换到 std::mutex 之前三思而后行。

#include "stdafx.h"
#include <Windows.h>
#include <mutex>
#include <thread>
#include <vector>
#include <chrono>
#include <iostream>

const int g_cRepeatCount = 1000000;
const int g_cThreadCount = 16;

double g_shmem = 8;
std::mutex g_mutex;
CRITICAL_SECTION g_critSec;

void sharedFunc( int i )
{
    if ( i % 2 == 0 )
        g_shmem = sqrt(g_shmem);
    else
        g_shmem *= g_shmem;
}

void threadFuncCritSec() {
    for ( int i = 0; i < g_cRepeatCount; ++i ) {
        EnterCriticalSection( &g_critSec );
        sharedFunc(i);
        LeaveCriticalSection( &g_critSec );
    }
}

void threadFuncMutex() {
    for ( int i = 0; i < g_cRepeatCount; ++i ) {
        g_mutex.lock();
        sharedFunc(i);
        g_mutex.unlock();
    }
}

void testRound(int threadCount)
{
    std::vector<std::thread> threads;

    auto startMutex = std::chrono::high_resolution_clock::now();
    for (int i = 0; i<threadCount; ++i)
        threads.push_back(std::thread( threadFuncMutex ));
    for ( std::thread& thd : threads )
        thd.join();
    auto endMutex = std::chrono::high_resolution_clock::now();

    std::cout << "std::mutex:       ";
    std::cout << std::chrono::duration_cast<std::chrono::microseconds>(endMutex - startMutex).count();
    std::cout << "us \n\r";

    threads.clear();
    auto startCritSec = std::chrono::high_resolution_clock::now();
    for (int i = 0; i<threadCount; ++i)
        threads.push_back(std::thread( threadFuncCritSec ));
    for ( std::thread& thd : threads )
        thd.join();
    auto endCritSec = std::chrono::high_resolution_clock::now();

    std::cout << "CRITICAL_SECTION: ";
    std::cout << std::chrono::duration_cast<std::chrono::microseconds>(endCritSec - startCritSec).count();
    std::cout << "us \n\r";
}

int _tmain(int argc, _TCHAR* argv[]) {
    InitializeCriticalSection( &g_critSec );

    std::cout << "Iterations: " << g_cRepeatCount << "\n\r";

    for (int i = 1; i <= g_cThreadCount; i = i*2) {
        std::cout << "Thread count: " << i << "\n\r";
        testRound(i);
        Sleep(1000);
    }

    DeleteCriticalSection( &g_critSec );

    // Added 10/27/2017 to try to prevent the compiler to completely
    // optimize out the code around g_shmem if it wouldn't be used anywhere.
    std::cout << "Shared variable value: " << g_shmem << std::endl;
    getchar();
    return 0;
}

2017 年 10 月 27 日更新 (1): 一些答案表明这不是一个现实的测试或不代表“现实世界”的场景。没错，这个测试试图测量 std::mutex 的 开销，它并不是试图证明 99% 的应用程序的差异可以忽略不计。

2017 年 10 月 27 日更新 (2): 自 Visual Studio 2015 (VC140) 以来，情况似乎发生了有利于 std::mutex 的变化。我使用了 VS2017 IDE，代码与上面完全相同，x64 版本配置，优化被禁用，我只是为每个测试切换了“平台工具集”。结果非常令人惊讶，我真的很好奇 VC140 中挂了什么。

2020 年 2 月 25 日更新 (3): 使用 Visual Studio 2019 (Toolset v142) 重新运行测试，情况依旧:std::mutex 比 CRITICAL_SECTION 快两到三倍。

关于c++ - 与 win32 CRITICAL_SECTION 相比的 std::mutex 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9997473/