c++ - 在 Linux 上锁定单个进程内数据访问的最快方法

Question

我正在尝试在 Windows 和 Linux 上锁定数据。

我用于测试的代码如下所示:

#include <mutex>
#include <time.h>
#include <iostream>
#include <vector>
#include <thread>

using namespace std;

mutex m; 

unsigned long long dd = 0; 

void RunTest() 
{ 
    for(int i = 0; i < 100000000; i++) 
    {
        unique_lock<mutex> lck{m}; 
        //boost::mutex::scoped_lock guard(m1);
        dd++;
    }
}


int main(int argc, char *argv[]) 
{ 

    clock_t tStart = clock(); 
    int tCount = 0; 
    vector<shared_ptr<thread>> threads;
    for(int i = 0; i < 10;i++) 
    {
        threads.push_back(shared_ptr<thread>{new thread(RunTest)}); 
    }

    RunTest();    

    for(auto t:threads) 
    {
        t->join();
    }

    cout << ((double)(clock() - tStart)/CLOCKS_PER_SEC) << endl;

    return 0; //v.size(); 
}

我正在测试g++ -O3 vs Visual Studio 2013 编译 Release模式。

当我使用unique_lock<mutex>时在同步方面，Linux 在大多数情况下都胜过 Windows，有时甚至明显胜过 Windows。

但是当我使用 Windows' CRITICAL_SECTION ，情况正好相反，Windows 代码变得比 Linux 上的代码快得多，特别是当线程数增加时。

这是我用于 Windows 关键部分测试的代码:

#include <stdafx.h>
#include <mutex>
#include <time.h>
#include <iostream>
//#include <boost/mutex>
#include <vector>
#include <thread>
#include<memory>

#include <Windows.h>

using namespace std;


mutex m;

unsigned long long dd = 0;

CRITICAL_SECTION critSec;

void RunTest()
{
    for (int i = 0; i < 100000000; i++)
    {
        //unique_lock<mutex> lck{ m };
        EnterCriticalSection(&critSec);
        dd++;
        LeaveCriticalSection(&critSec);
    }
}


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

    clock_t tStart = clock();
    int tCount = 0;
    vector<shared_ptr<thread>> threads;
    for (int i = 0; i < 10; i++)
    {
        threads.push_back(shared_ptr<thread>{new thread(RunTest)});
    }

    RunTest();

    for (auto t : threads)
    {
        t->join();
    }

    cout << ((double)(clock() - tStart) / CLOCKS_PER_SEC) << endl;
    DeleteCriticalSection(&critSec);

    return 0;
}

我理解为什么会发生这种情况的方式是关键部分是特定于流程的。

我将进行的大部分同步都将在单个进程内进行。

Linux 上有没有比互斥锁或 Windows 临界区更快的东西？

Answer 1

首先，您的代码存在巨大的竞争问题，因此不能反射(reflect)任何正常的情况，并且非常不适合基准测试。这是因为，大多数互斥实现都针对不需要等待即可获取锁的情况进行了优化，在其他情况下，即高争用，这涉及阻塞线程，则互斥开销变得微不足道，您应该重新设计系统以获得不错的改进，例如拆分为多个锁，使用无锁算法或使用事务内存(在某些 haswell 处理器或软件实现中作为 TSX 扩展提供)。

现在，为了解释其中的差异，Windows 上的 CriticalSection 实际上会在解析为线程阻塞互斥体之前执行短时间自旋锁。由于阻塞线程涉及数量级的开销，因此在低争用情况下，自旋锁可能会大大减少陷入此类开销的机会(请注意，在高争用情况下，自旋锁实际上会使情况变得更糟)。

在 Linux 上，您可能想要研究快速用户空间互斥体或 futex，它采用了类似的想法。