Разница между memory_order_consume и memory_order_acquire

(выделение добавлено)

В комментарии ниже я буду сокращать нижеследующее:

• По порядку зависимостей до: дата рождения
• Переход между потоками происходит раньше: ITHB
• Происходит до: HB
• Последовательность до: SeqB

Давайте рассмотрим, как это применимо. У нас есть 4 соответствующие операции с памятью, которые мы назовем вычислениями A, B, C и D:

Тема 1:

y.store (20);             //    Release; Evaluation A
x.store (10);             //    Release; Evaluation B

Тема 2:

if (x.load() == 10) {     //    Consume; Evaluation C
  assert (y.load() == 20) //    Consume; Evaluation D
  y.store (10)
}

Чтобы доказать, что утверждение никогда не срабатывает, мы пытаемся доказать, что A всегда является видимым побочным эффектом в D. В соответствии с 5.1.2.4 (15) имеем:

A SeqB B DOB C SeqB D

который представляет собой конкатенацию, оканчивающуюся на DOB, за которой следует SeqB. Это явно регулируется (17) не конкатенацией ITHB, несмотря на то, что говорит (16).

Мы знаем, что, поскольку A и D не находятся в одном и том же потоке выполнения, A не является SeqB D; Следовательно, ни одно из двух условий в (18) для HB не выполняется, и A не делает HB D.

Отсюда следует, что A не виден D, так как одно из условий (19) не выполняется. Утверждение может завершиться ошибкой.

Как это может происходить, описано здесь, в обсуждении модели памяти стандарта C++ и здесь, Раздел 4.2 Зависимости управления:

1. (Некоторое время вперед) Предсказатель ветвления потока 2 предполагает, что будет взят if.
2. Поток 2 приближается к предсказанной взятой ветке и начинает спекулятивную выборку.
3. Поток 2 работает не по порядку и предположительно загружает 0xGUNK из y (оценка D). (Может, его еще не выгнали из кеша?).
4. Поток 1 сохраняет 20 в y (Оценка A)
5. Поток 1 сохраняет 10 в x (оценка B)
6. Поток 2 загружает 10 из x (оценка C)
7. Тема 2 подтверждает, что if взято.
8. Предполагаемая нагрузка потока 2, равная y == 0xGUNK, фиксируется.
9. Поток 2 не подтверждается.

Причина, по которой разрешено переупорядочивать оценку D перед C, заключается в том, что consume не запрещает это. Это отличается от acquire-load, который предотвращает изменение порядка загрузки/сохранения после в программном порядке перед. Опять же, в 5.1.2.4(15) указано, что операция потребления, участвующая в отношении «предшествующий порядок зависимостей», обеспечивает упорядочение только в отношении операций, от которых эта операция потребления действительно несет зависимость, и совершенно определенно нет зависимости между двумя нагрузками.

Проверка CppMem

CppMem – это инструмент, помогающий исследовать сценарии доступа к общим данным. в моделях памяти C11 и C++11.

Для следующего кода, который приближается к сценарию в вопросе:

int main() {
  atomic_int x, y;
  y.store(30, mo_seq_cst);
  {{{  { y.store(20, mo_release);
         x.store(10, mo_release); }
  ||| { r3 = x.load(mo_consume).readsvalue(10);
        r4 = y.load(mo_consume); }
  }}};
  return 0; }

Инструмент сообщает о двух непротиворечивых сценариях без гонки, а именно:

В котором y=20 успешно читается, и

В котором читается "устаревшее" значение инициализации y=30. Круг от руки мой.

Напротив, когда для нагрузок используется mo_acquire, CppMem сообщает только об одном согласованном сценарии без состязаний, а именно о правильном:

в котором читается y=20.