Многопоточная программа зависла в оптимизированном режиме, но нормально работает в -O0

Я написал простую многопоточную программу следующим образом:

static bool finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Он ведет себя нормально в режиме отладки в Visual studio или -O0в gc c и выводит результат через 1несколько секунд. Но он застрял и ничего не печатает в режиме выпуска или -O1 -O2 -O3.

UB Это касается двух потоков, обращающихся к неатомарным неохраняемым переменным finished. Вы можете сделать finishedтип, std::atomic<bool>чтобы исправить это.

Мое исправление:

#include <iostream>
#include <future>
#include <atomic>

static std::atomic<bool> finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Вывод:

result =1023045342
main thread id=140147660588864

Живая Демо на Колиру

Кто-то может подумать: «Это bool- возможно, один бит. Как это может быть неатомным? (Я сделал, когда я начал с многопоточности самостоятельно.)

Но обратите внимание, что отсутствие слез не единственное, что std::atomicдает вам. Это также делает одновременный доступ для чтения и записи из нескольких потоков четко определенным, не позволяя компилятору предполагать, что повторное чтение переменной всегда будет видеть одно и то же значение.

Создание boolнеохраняемого, неатомного может вызвать дополнительные проблемы:

• Компилятор может решить оптимизировать переменную в регистр или даже несколько обращений CSE в один и вывести нагрузку из цикла.
• Переменная может быть кэширована для ядра процессора. (В реальной жизни, процессоры имеют когерентные кэша . Это не проблема, но стандарт C ++ ослаблен достаточно , чтобы покрыть гипотетические C ++ реализации на некогерентной общую памяти , где atomic<bool>с memory_order_relaxedмагазином / нагрузка будет работать, но там , где volatileне будет. Использование энергозависимым для этого будет UB, даже если он работает на реальных реализациях C ++.)

Чтобы этого не случилось, компилятору должно быть явно сказано не делать этого.

Я немного удивлен развивающейся дискуссией о потенциальном отношении volatileк этой проблеме. Таким образом, я хотел бы потратить свои два цента:

• Изменчиво полезно с потоками
• Кто боится большого плохого оптимизирующего компилятора? ,

Ответ Шеффа описывает, как исправить ваш код. Я думал, что добавлю немного информации о том, что на самом деле происходит в этом случае.

Я скомпилировал ваш код в Godbolt, используя уровень оптимизации 1 ( -O1). Ваша функция компилируется так:

func():
  cmp BYTE PTR finished[rip], 0
  jne .L4
.L5:
  jmp .L5
.L4:
  mov eax, 0
  ret

Итак, что здесь происходит? Во-первых, у нас есть сравнение: cmp BYTE PTR finished[rip], 0- это проверяет, finishedявляется ли оно ложным или нет.

Если это не ложь (иначе истина), мы должны выйти из цикла при первом запуске. Это достигается путем jne .L4которого J umps при п OT е каче к этикетке , .L4где значение i( 0) хранится в регистре для последующего использования и функция возвращает.

Если это является ложным , однако, мы переходим к

.L5:
  jmp .L5

Это безусловный переход, для обозначения .L5которого именно так и происходит сама команда перехода.

Другими словами, поток помещается в бесконечный цикл занятости.

Так почему же это произошло?

Что касается оптимизатора, потоки находятся за пределами его компетенции. Предполагается, что другие потоки не читают и не записывают переменные одновременно (потому что это будет гонка данных UB). Вы должны сказать ему, что он не может оптимизировать доступ. Здесь приходит ответ Шеффа. Я не буду его повторять.

Поскольку оптимизатору не сообщают, что finishedпеременная может потенциально измениться во время выполнения функции, он видит, что finishedона не изменена самой функцией, и предполагает, что она постоянна.

Оптимизированный код обеспечивает два пути кода, которые будут получены при вводе функции с постоянным значением bool; либо он запускает цикл бесконечно, либо цикл никогда не запускается.

у -O0компилятора (как и ожидалось) не оптимизируется тело цикла и сравнение отсюда:

func():
  push rbp
  mov rbp, rsp
  mov QWORD PTR [rbp-8], 0
.L148:
  movzx eax, BYTE PTR finished[rip]
  test al, al
  jne .L147
  add QWORD PTR [rbp-8], 1
  jmp .L148
.L147:
  mov rax, QWORD PTR [rbp-8]
  pop rbp
  ret

поэтому функция, когда она неоптимизирована, работает, отсутствие атомарности здесь обычно не является проблемой, потому что код и тип данных просты. Вероятно, худшее, с чем мы могли бы здесь столкнуться, - это значение i, которое на единицу меньше, чем должно быть.

Более сложная система со структурами данных может привести к повреждению данных или неправильному выполнению.

Ради полноты кривой обучения; Вы должны избегать использования глобальных переменных. Вы хорошо поработали, сделав его статичным, поэтому он будет локальным для модуля перевода.

Вот пример:

class ST {
public:
    int func()
    {
        size_t i = 0;
        while (!finished)
            ++i;
        return i;
    }
    void setFinished(bool val)
    {
        finished = val;
    }
private:
    std::atomic<bool> finished = false;
};

int main()
{
    ST st;
    auto result=std::async(std::launch::async, &ST::func, std::ref(st));
    std::this_thread::sleep_for(std::chrono::seconds(1));
    st.setFinished(true);
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Жить на wandbox