На многоядерном x86, LOCK необходимо как префикс для XCHG?

Ответ 1

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

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

7.1.2.1 говорит:

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

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

Аналогично,

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

XCHG:

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

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

Ответ 2

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

Ответ 3

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

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