Порядок памяти с несколькими хранилищами
Рассмотрим пример ниже. Предположим, что barrier инициализируется значением 0.
Существует один поток-производитель и два потока-потребителя, которые постоянно проверяют barrier. Если барьер установлен, они уменьшаются runcnt. Поток производителя ждет, пока runcnt достигнет 0. Меня смущает порядок выполнения нескольких операций хранения внутри производителя.
Если порядок такой, как написано, я думаю, код будет работать так, как ожидалось. Но если хранилище barrier будет переупорядочено раньше магазина runcnt, похоже, проверка утверждения завершится неудачей.
Я что-то упускаю? Есть ли способ это исправить?
extern atomic<int> barrier[2];
atomic_int runcnt{0};
void producer() {
runcnt.store(2, memory_order_relaxed);
barrier[0].store(1, memory_order_relaxed);
barrier[1].store(1, memory_order_relaxed);
while (runcnt.load(memory_order_relaxed)) {
cpu_pause();
}
}
void consumer(unsigned index) {
while (true) {
if (barrier[index].exchange(false, memory_order_relaxed)) {
int prev = runcnt.fetch_sub(1, memory_order_relaxed);
assert(prev > 0);
}
}
}
Ответы 2
Если порядок такой, как написано. Вы имеете в виду, если операции станут видимыми в порядке, который также будет разрешен seq_cst? Конечно, вы могли бы потребовать этого с помощью seq_cst для всех операций.
Я думаю, что минимум в читалке — чтобы barrier[i].exchange было acquire.
А на стороне записи оба хранилища barrier[i] должны быть release или поставить одно std::atomic_thread_fence(release) сразу после runcnt.store, чтобы оно было между этим и любым барьерным хранилищем.
Это заставляет exchange синхронизироваться с тем хранилищем barrier, которое оно загружает, при условии, что оно загрузило 1, поэтому тело if вообще работает.
runcnt.store(relaxed) ; barrier[0].store(release) ; barrier[1].store(relaxed) было бы недостаточно в модели памяти C++ или даже при компиляции для некоторых ISA: окончательное расслабленное хранилище может пройти через хранилище релизов, потому что это только односторонний барьер. В этом ключевое различие между заборами и операциями: https://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/ . Даже создания среднего магазина seq_cst будет недостаточно, это все равно просто операция, а не двустороннее ограждение.
Спасибо @peter-cordes. Я хотел бы сосредоточиться на решении с помощью std::atomic_thread_fence(release) Что меня смущает, так это то, что мы можем исправить код, только изменив сторону производителя, не добавляя дополнительных барьеров получения у потребителя.
@Roman: Для ограничения выпуска у производителя по-прежнему требуется, чтобы читатель использовал exchage(acquire), так же, как и в магазинах выпусков. Извините, если это не было ясно из ответа; Я только что обдумывал альтернативный способ получить достаточный заказ в средстве записи, который был бы дешевле на ISA, таких как ARMv7, где каждый магазин выпуска включал бы барьер, по крайней мере, такой же сильный, как fence(release), на самом деле fence(seq_cst), к сожалению. (ARMv8 это исправляет.). Возможно, минимальный заказ читателя должен быть отдельным абзацем.
Но зачем нам приобретать данные, если других переменных, как в этом примере, нет? Можно ли переупорядочить fetch_sub до чтения барьера?
@Roman: Да, расслабленные RMW на разных объектах являются отдельно атомарными, но не упорядоченными. что угодно, включая друг друга. Без «случилось-раньше» в модели памяти ISO C++ нет никаких гарантий. Я не удивлюсь, если никакие ISA не смогут сломать это на практике, поскольку это RMW, который включает в себя хранилище перед ветвью, и IDK, если какие-либо ISA действительно могут иметь два расслабленных атомарных RMW одновременно в разных местах, например, сторона загрузки fetch_sub начинается спекулятивно благодаря предсказанию ветвей.
Поэтому, чтобы сохранить здравомыслие, мне следует заменить RMW на нагрузки, когда я думаю о семантике порядка памяти, понятно!
Как отметил @peter-cordes, в отличие от магазинов обычных выпусков, которые являются однонаправленными, std::atomic_thread_fence(release) служит двунаправленным барьером между магазинами (более поздние загрузки все равно можно переупорядочить через него).
Таким образом, это фиксированный код, также использующий нагрузку acquire в потребителе:
void producer() {
runcnt.store(2, memory_order_relaxed);
std::atomic_thread_fence(release); // <- Prevents reordering of barrier stores before runcnt.store.
barrier[0].store(1, memory_order_relaxed);
barrier[1].store(1, memory_order_relaxed);
while (runcnt.load(memory_order_relaxed)) {
cpu_pause();
}
}
void consumer(unsigned index) {
while (true) {
// we "ignore" the branching and RMW when we plan
// memory order semantics.
// `acquire` prevents fetch_sub being reordered before the `exchange`.
if (barrier[index].exchange(false, memory_order_acquire)) {
int prev = runcnt.fetch_sub(1, memory_order_relaxed);
assert(prev > 0);
}
}
}
Ограждение выпуска предотвращает переупорядочение LoadStore. Два, которые он не блокирует, — это LoadLoad и StoreLoad. preshing.com/20120913/acquire-and-release-semantics / preshing.com/20130922/acquire-and-release-fences . Но да, полезным свойством здесь является блокировка переупорядочения StoreStore. (Чтобы реализовать семантику C++ всего, что происходит до того, как происходит ограничение, то есть до любого сохранения после ограничения.) Если ограничения и операции выпуска допускают переупорядочение LoadStore, чтение переменной, пока вы удерживаете блокировку, может получить значение после критической секции следующего потока. уже написал