На многоядерном x86 нужен ли LOCK в качестве префикса для XCHG?

Документация Intel кажется довольно ясной, что она избыточна.

IA-32 Руководство разработчика программного обеспечения для архитектуры Intel®, том 3A: Руководство по системному программированию, часть 1

7.1.2.1 говорит:

Операции, в которых процессор автоматически следует семантике LOCK, следующие:

• При выполнении инструкции XCHG, которая ссылается на память.

Так же,

Руководство разработчика программного обеспечения для архитектур Intel® 64 и IA-32, том 2B: Справочник по набору инструкций, N-Z

XCHG:

При обращении к операнду памяти протокол блокировки процессора автоматически реализуется на время операции обмена, независимо от наличия или отсутствия префикса LOCK или значения IOPL.

Обратите внимание, что на самом деле это не означает, что сигнал LOCK# устанавливается независимо от того, используется префикс LOCK или нет, 7.1.4 описывает, как на более поздних процессорах семантика блокировки сохраняется без LOCK#, если ячейка памяти кэшируется. Умно, и определенно над моей головой.

Начиная с 386 дней, xchg будет утверждать сигнал блокировки независимо от того, поместите ли вы на него префикс блокировки. документация Intel довольно четко описывает это в справочнике по набору инструкций IA-32 N-Z.

Согласно Руководству по эксплуатации 80386, BUS LOCK утверждается на время обмена. Префикс LOCK не имеет приоритета для этой операции, равно как и значение Уровень привилегий ввода/вывода.

Мое предложение состоит в том, что, поскольку в документации указано, что BUS LOCK утверждается независимо от наличия префикса LOCK, в остальном LOCK XCHG EAX, mem безопасен. Если сомневаетесь, добавьте LOCK.