Может ли переупорядочение памяти во время компиляции привести к тупикам?
Во время просмотра этот говорить о реализации атомарного C ++ 11 в LLVM был этот кусок кода
-- Initially --
int x = 0;
std::atomic<bool> flag1{false}, flag2{false};-- Thread 1 --
x = 42;
flag1.store(true, std::memory_order_release);
while(!flag2.load(std::memory_order_acquire));
x = 43;-- Thread 2 --
while(!flag1.load(std::memory_order_acquire));
printf("%d", x);
flag2.store(true, std::memory_order_release);
Я считаю, что этот код для гонки данных свободен (как об этом говорит докладчик): он никогда не будет печатать ничего, кроме 42,
Однако я не уверен тот это будет когда-либо печатать 42, Мой вопрос таков: нельзя ли компилятору переупорядочить хранилище после цикла while в потоке 1, чтобы оба потока зашли в тупик? Или какая часть стандарта C ++ 11 предотвращает такое поведение?
Решение
Компилятор НИКОГДА не должен перемещать хранилище для любого (видимого извне) значения за пределом выпуска и не должен перемещать показания выше ограничителя получения. Это главное назначение заборов.
Здесь также может быть задействована и другая семантика, например, если необходимо очистить кэш, ограничитель выпуска сбрасывает любые «записи», ожидающие этого ЦП, в основную память. Точно так же, граница получения должна будет сбрасывать все или выбранные регионы, чтобы новые значения считывались до того, как будет выпущено следующее чтение.
Тем не менее, все современные процессоры имеют согласованную память между процессорами, так что это не проблема — это может быть проблемой в некоторых необычных / маленьких или старых процессорах, которые имеют кэш, который предполагает, что другие процессоры не будут считывать ту же память, что и в кеш. Если вы работаете с неоднородными процессорами, которые не связаны друг с другом, то обслуживание кеша также становится проблемой — вам нужно будет убедиться, что кеши очищены правильно. Опять же, в некоторой степени специализированная область, но может быть важным фактором в многопроцессорных системах.
Другие решения