Visual Studio 2012 中的 std::atomic_flag 静态初始化线程是否安全？

Question

Visual Studio 2012 没有实现线程安全静态初始化的 C++11 标准 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm)。我有一个本地静态函数，我需要保证它会以线程安全的方式进行初始化。以下是 Visual Studio 2012 中的不是线程安全的：

struct MyClass
{
    int a;
    MyClass()
    {
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
        a = 5;
    }
};

void foo()
{
    static MyClass instance;
    std::cout << instance.a << '\n';
}

int main()
{
    std::thread a(foo);
    std::thread b(foo);
    a.join();
    b.join();

    system("pause");
}

上述程序在 Visual Studio 2012 上的输出很可能是：

0
5

我需要解决这个问题，我正在尝试找到一种方法来仅使用函数局部静态（没有全局或类级静态）。

我最初的想法是使用互斥锁，但它遇到了同样的静态初始化线程安全问题。如果我在 foo 中有一个静态 st::mutex ，那么第二个线程可能会在它处于无效状态时获得互斥锁的副本。

另一个选项是添加一个 std::atomic_flag 自旋锁。问题是，std::atomic_flag 初始化线程在 Visual Studio 2012 中是否安全？

void foo()
{
    // is this line thread safe?
    static std::atomic_flag lock = ATOMIC_FLAG_INIT;
    // spin lock before static construction
    while (lock.test_and_set(std::memory_order_acquire));
    // construct an instance of MyClass only once
    static MyClass instance;
    // end spin lock
    lock.clear(std::memory_order_release);
    // the following is not thread safe
    std::cout << instance.a << '\n';
}

在上面的代码中，两个线程是否有可能通过自旋锁，还是保证只有其中一个可以通过？不幸的是，我想不出一种简单的方法来测试它，因为我不能在 atomic_flag 初始化程序中放入一些东西来减慢它，就像我在一个类中可以做到的那样。但是，我想确保我的程序不会因为我做了一个无效的假设而突然崩溃。

Answer 1

C++11 的 6.7.4 节指出，具有静态存储持续时间的变量被初始化为线程安全的：

如果控制在变量初始化的同时进入声明，并发执行将等待初始化完成。

但是 VC++ 2012 或 2013 Preview 都没有实现这一点，所以是的，你需要一些保护来使你的函数线程安全。

C++11 在 29.7.4 部分也提到了 ATOMIC_FLAG_INIT：

宏ATOMIC_FLAG_INIT 应被定义为可用于将atomic_flag 类型的对象初始化为清除状态。对于静态持续时间对象，该初始化应该是静态的。

VC++ 确实恰好正确地实现了这一点。 ATOMIC_FLAG_INIT 在 VC++ 中是 0，并且 VC++ 在应用程序启动时对所有静态变量进行零初始化，而不是在函数调用中。所以，你使用它是安全的，不会有初始化lock的竞争。

测试代码：

struct nontrivial
{
    nontrivial() : x(123) {}
    int x;
};

__declspec(dllexport) int next_x()
{
    static nontrivial x;
    return ++x.x;
}

__declspec(dllexport) int next_x_ts()
{
    static std::atomic_flag flag = ATOMIC_FLAG_INIT;

    while(flag.test_and_set());
    static nontrivial x;
    flag.clear();

    return ++x.x;
}

next_x:

                mov     eax, cs:dword_1400035E4
                test    al, 1                   ; checking if x has been initialized.
                jnz     short loc_140001021     ; if it has, go down to the end.
                or      eax, 1
                mov     cs:dword_1400035E4, eax ; otherwise, set it as initialized.
                mov     eax, 7Bh                 
                inc     eax                     ; /O2 is on, how'd this inc sneak in!?
                mov     cs:dword_1400035D8, eax ; init x.x to 124 and return.
                retn
loc_140001021:
                mov     eax, cs:dword_1400035D8
                inc     eax
                mov     cs:dword_1400035D8, eax
                retn

next_x_ts:

loc_140001032:
                lock bts cs:dword_1400035D4, 0  ; flag.test_and_set().
                jb      short loc_140001032     ; spin until set.
                mov     eax, cs:dword_1400035E0
                test    al, 1                   ; checking if x has been initialized.
                jnz     short loc_14000105A     ; if it has, go down to end.
                or      eax, 1                  ; otherwise, set is as initialized.
                mov     cs:dword_1400035E8, 7Bh ; init x.x with 123.
                mov     cs:dword_1400035E0, eax

loc_14000105A:
                lock btr cs:dword_1400035D4, 0  ; flag.clear().
                mov     eax, cs:dword_1400035E8
                inc     eax
                mov     cs:dword_1400035E8, eax
                retn

您可以在此处看到next_x 绝对不是线程安全的，但next_x_ts 从未在cs:dword_1400035D4 处初始化flag 变量——它在应用程序启动时初始化为零，因此没有竞争和next_x_ts 是线程安全的。