Програма багатопотокової роботи застрягла в оптимізованому режимі, але працює нормально в -00

Я написав прості багатопотокові програми так:

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 в один і підняти навантаження з циклу.
• Змінна може бути кешована для ядра CPU. (У реальному житті процесори мають когерентні кеші . Це не реальна проблема, але стандарт 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, коли n ot e qual позначає, .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