Требуется ли барьер памяти или атомарная операция в цикле ожидания занятости?

Это важно: в C ++ volatile имеет ничего такого вообще делать с параллелизмом! Цель volatile это рассказать компилятор что он не должен оптимизировать доступ к затронутому объекту. Оно делает не сказать ЦПУ что-нибудь, в первую очередь потому, что ЦП уже знает, будет ли память volatile или нет. Цель volatile эффективно бороться с отображением памяти ввода-вывода.

Стандарт C ++ очень ясно показывает в разделе 1.10 [intro.multithread], что несинхронизированный доступ к объекту, который изменен в одном потоке и доступен (изменен или прочитан) в другом потоке, является неопределенным поведением. Примитивы синхронизации, избегающие неопределенного поведения, являются компонентами библиотеки, такими как атомарные классы или мьютексы. В этом пункте упоминается volatile только в контексте сигналов (т. е. как volatile sigatomic_t) и в контексте продвижения вперед (то есть, что поток в конечном итоге сделает что-то, что имеет наблюдаемый эффект, например, доступ к volatile объект или делать ввод / вывод). Там нет упоминания о volatile в сочетании с синхронизацией.

Таким образом, несинхронизированная оценка переменной, разделяемой между потоками, приводит к неопределенному поведению. Объявлено ли это volatile или не имеет значения для этого неопределенного поведения.

От Страница Википедии о барьерах памяти:

… Другие архитектуры, такие как Itanium, предоставляют отдельные барьеры памяти «получения» и «освобождения», которые обращают внимание на видимость операций чтения после записи с точки зрения читателя (приемника) или пишущего устройства (источника) соответственно.

Для меня это означает, что Itanium требует подходящего ограждения, чтобы сделать чтение / запись видимыми для других процессоров, но на самом деле это может быть сделано только для целей упорядочения. Вопрос, я думаю, действительно сводится к:

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

С точки зрения общей легальности C ++, одного атомарного теста и набора в вашем примере недостаточно, поскольку он реализует только один забор, который позволит вам увидеть начальное состояние *lock при входе в цикл while, но не видеть, когда он изменяется (что приводит к неопределенному поведению, поскольку вы читаете переменную, которая изменяется в другом потоке без синхронизации) — поэтому ответ на ваш вопрос (1.1 / 3) нет.

С другой стороны, на практике ответ на (1.2 / 2) — да (дано Изменчивая семантика GCC), поскольку архитектура гарантирует согласованность кэша без явных ограничений памяти, что справедливо для x86 и, вероятно, для многих архитектур, но я не могу дать однозначного ответа на вопрос, верно ли это для всех архитектур, которые поддерживает GCC. Однако, как правило, неразумно полагаться на конкретное поведение кода, которое является технически неопределенным поведением в соответствии со спецификацией языка, особенно если возможно получить тот же результат без этого.

Кстати, учитывая что memory_order_relaxed существует, кажется, мало причин не использовать его в этом случае, вместо того, чтобы пытаться оптимизировать вручную с помощью неатомарных операций чтения, т.е. изменить цикл while в вашем примере на:

    while (atomic_load_explicit(lock, memory_order_relaxed)) {
cpu_relax();
}

Например, на x86_64 атомная нагрузка становится обычной mov инструкция и оптимизированный вывод сборки в основном такие же, как и в вашем исходном примере.