VC ++仍然按顺序 - 一致性明智吗？(Is VC++ still broken Sequentially-Consistent-wise?)

 我观察了（大部分） Herb Sutter的atmoic <>武器视频 ，我想用样本内的循环测试“条件锁定”。 显然，尽管（如果我理解正确的话）C ++ 11标准说下面的例子应该正常工作并且顺序一致，但事实并非如此。 
 
 在你阅读之前，我的问题是：这是正确的吗？ 编译器是否损坏？ 我的代码是否被破解 - 我在这里遇到了一个我错过的竞争条件？ 我如何绕过这个？ 
 
 我尝试过3种不同版本的Visual C ++：VC10 professional，VC11 professional和VC12 Express（== Visual Studio 2013 Desktop Express）。 
 
 下面是我用于Visual Studio 2013的代码。对于其他版本，我使用boost而不是std，但是这个想法是一样的。 
 
#include <iostream>
#include <thread>
#include <mutex>

int a = 0;
std::mutex m;

void other()
{
    std::lock_guard<std::mutex> l(m);
    std::this_thread::sleep_for(std::chrono::milliseconds(2));
    a = 999999;
    std::this_thread::sleep_for(std::chrono::seconds(2));
    std::cout << a << "\n";
}

int main(int argc, char* argv[])
{
    bool work = (argc > 1);

    if (work)
    {
        m.lock();
    }

    std::thread th(other);
    for (int i = 0; i < 100000000; ++i)
    {
        if (i % 7 == 3)
        {
            if (work)
            {
                ++a;
            }
        }
    }

    if (work)
    {
        std::cout << a << "\n";
        m.unlock();
    }

    th.join();
}
 
 总结代码的思想：全局变量a受全局互斥量m保护。 假设没有命令行参数（ argc==1 ），则运行other()的线程是唯一应该访问全局变量a的线程。 
 
 该程序的正确输出是打印999999。 
 
 但是，由于编译器循环优化（使用寄存器循环增量，并且在循环结束时将值复制回a ），所以尽管不应该这样，但程序会修改a 。 
 
 这发生在所有3个VC版本中，尽管在VC12中的这个代码示例中，我不得不调用一些调用sleep()来使其中断。 
 
 这是一些汇编代码（在这次运行中的地址是0x00f65498 ）： 
 
 循环初始化 - 来自a值被复制到edi 
 
    27:     for (int i = 0; i < 100000000; ++i)
00F61543  xor         esi,esi  
00F61545  mov         edi,dword ptr ds:[0F65498h]  
00F6154B  jmp         main+0C0h (0F61550h)  
00F6154D  lea         ecx,[ecx]  
    28:     {
    29:         if (i % 7 == 3)
 
 在条件内增加，并在循环之后无条件复制回位置 
 
    30:         {
    31:             if (work)
00F61572  mov         al,byte ptr [esp+1Bh]  
00F61576  jne         main+0EDh (0F6157Dh)  
00F61578  test        al,al  
00F6157A  je          main+0EDh (0F6157Dh)  
    32:             {
    33:                 ++a;
00F6157C  inc         edi  
    27:     for (int i = 0; i < 100000000; ++i)
00F6157D  inc         esi  
00F6157E  cmp         esi,5F5E100h  
00F61584  jl          main+0C0h (0F61550h)  
    32:             {
    33:                 ++a;
00F61586  mov         dword ptr ds:[0F65498h],edi  
    34:             }
 
 程序的输出是0 。 

I watched (most of) Herb Sutter's the atmoic<> weapons video, and I wanted to test the "conditional lock" with a loop inside sample. Apparently, although (if I understand correctly) the C++11 standard says the below example should work properly and be sequentially consistent, it is not.
 
Before you read on, my question is: Is this correct? Is the compiler broken? Is my code broken - do I have a race condition here which I missed? How do I bypass this?
 
I tried it on 3 different versions of Visual C++: VC10 professional, VC11 professional and VC12 Express (== Visual Studio 2013 Desktop Express).
 
Below is the code I used for the Visual Studio 2013. For the other versions I used boost instead of std, but the idea is the same.
 
#include <iostream>
#include <thread>
#include <mutex>

int a = 0;
std::mutex m;

void other()
{
    std::lock_guard<std::mutex> l(m);
    std::this_thread::sleep_for(std::chrono::milliseconds(2));
    a = 999999;
    std::this_thread::sleep_for(std::chrono::seconds(2));
    std::cout << a << "\n";
}

int main(int argc, char* argv[])
{
    bool work = (argc > 1);

    if (work)
    {
        m.lock();
    }

    std::thread th(other);
    for (int i = 0; i < 100000000; ++i)
    {
        if (i % 7 == 3)
        {
            if (work)
            {
                ++a;
            }
        }
    }

    if (work)
    {
        std::cout << a << "\n";
        m.unlock();
    }

    th.join();
}
 
To summarize the idea of the code: The global variable a is protected by the global mutex m. Assuming there are no command line arguments (argc==1) the thread which runs other() is the only one which is supposed to access the global variable a.
 
The correct output of the program is to print 999999.
 
However, because of the compiler loop optimization (using a register for in-loop increments and at the end of the loop copying the value back to a), a is modified by the assembly even though it's not supposed to.
 
This happened in all 3 VC versions, although in this code example in VC12 I had to plant some calls to sleep() to make it break.
 
Here's some of the assembly code (the adress of a in this run is 0x00f65498):
 
Loop initialization - value from a is copied into edi
 
    27:     for (int i = 0; i < 100000000; ++i)
00F61543  xor         esi,esi  
00F61545  mov         edi,dword ptr ds:[0F65498h]  
00F6154B  jmp         main+0C0h (0F61550h)  
00F6154D  lea         ecx,[ecx]  
    28:     {
    29:         if (i % 7 == 3)
 
Increment within the condition, and after the loop copied back to the location of a unconditionally
 
    30:         {
    31:             if (work)
00F61572  mov         al,byte ptr [esp+1Bh]  
00F61576  jne         main+0EDh (0F6157Dh)  
00F61578  test        al,al  
00F6157A  je          main+0EDh (0F6157Dh)  
    32:             {
    33:                 ++a;
00F6157C  inc         edi  
    27:     for (int i = 0; i < 100000000; ++i)
00F6157D  inc         esi  
00F6157E  cmp         esi,5F5E100h  
00F61584  jl          main+0C0h (0F61550h)  
    32:             {
    33:                 ++a;
00F61586  mov         dword ptr ds:[0F65498h],edi  
    34:             }
 
And the output of the program is 0.

原文：https://stackoverflow.com/questions/24313168