c++ - 为什么这里获取系统时间时使用 `atomic_signal_fence`

Question

我在 github repo 中找到了这个函数它实现了一个无锁队列。此函数使用 QueryPerformanceCounter 获取准确的系统时间。

#define CompilerMemBar() std::atomic_signal_fence(std::memory_order_seq_cst)
SystemTime getSystemTime()
{
    LARGE_INTEGER t;
    CompilerMemBar();
    if (!QueryPerformanceCounter(&t)) {
        return static_cast<SystemTime>(-1);
    }
    CompilerMemBar();

    return static_cast<SystemTime>(t.QuadPart);
}

我注意到有两个 CompilerMemBar()，我认为这是为了防止编译器重新排序。然而，在我在 github 上搜索了一些代码之后，我发现用编译器屏障包装 QueryPerformanceCounter 可能不是一种常见的做法。所以我的问题是这些障碍是为了处理一些特殊情况吗？可能重新排序会影响我们获得的系统时间的精度？但我不知道他们会怎么做，因为我认为即使 WINAPI 调用或返回语句被重新排序，它似乎对精度也没有影响。

Answer 1

代码开发人员可能认为，如果编译器不能对语句重新排序，它会产生更准确的结果。例如:

expensive1(); // takes a lot of time

SystemTime t = getSystemTime();

expensive2();

如果您想要两次昂贵调用之间的确切时间戳(或性能计数)，您不希望编译器使用其中之一重新排序 getSystemTime()因为它可能会影响 QueryPerformanceCounter 返回的值。

这是否现实，我不知道。编译器必须知道函数内部发生了什么，否则它不会重新排序任何东西(如果 expensive 调用是在预编译库中定义的，则无论如何都不会对语句进行重新排序)。

但至少这种做法似乎并没有太大的害处。std::atomic_signal_fence(std::memory_order_seq_cst) 防止编译器重新排序，但它不会产生 CPU 栅栏指令。