Intel 64 и IA-32 | Атомные операции, включая Semantic Semantic

Question

Согласно Руководству по программному обеспечению программного обеспечения Intel 64 и IA-32 Architectures, префикс сигнала блокировки гарантирует, что процессор имеет исключительное использование любой общей памяти, когда сигнал утверждается ». Это может быть в форме автобуса или блокировки кеша.

Но - и это причина, по которой я задаю этот вопрос - мне это не ясно, если этот префикс также предоставляет какой -либо борье памяти.

Я разрабатываю NASM в многопрофильной среде и необходим внедрять атомные операции с дополнительной семантикой приобретения и/или выпуска.

Итак, нужно ли мне использовать инструкции MFENCE, SFENCE и LFENCE или это будет излишним?

Answer 1

Нет, нет необходимости использовать инструкции MFENCE, SFENCE and LFENCE в отношениях с LOCK префикс.

MFENCE, SFENCE and LFENCE Гарантия инструкции видимость памяти во всех ядрах процессоров. На случай MOV Инструкция не может быть использована с LOCK Префикс, поэтому, чтобы быть уверенным в том, что результат перемещения памяти видна всем ядрам процессора, мы должны быть уверены, что кеш ЦП промывается до оперативной памяти и что мы достигаем инструкций по ограждению.

РЕДАКТИРОВАТЬ: Подробнее о заблокированных атомных операциях из руководства Intel:

Заблокированные атомные операции

32-битные процессоры IA-32 поддерживают заблокированные атомные операции в местах в системной памяти. Эти операции обычно используются для управления общими структурами данных (например, семафоры, дескрипторы сегмента, системные сегменты или таблицы страниц), в которых два или более процессоров могут одновременно пытаться изменять одно и то же поле или флаг. Процессор использует три взаимозависимых механизма для выполнения заблокированных атомных операций:

• Гарантированные атомные операции

• Блокировка шины, используя сигнал блокировки# и префикс инструкции по блокировке

• протоколы когерентности кэша, которые обеспечивают, чтобы атомные операции могли быть выполнены в кэшированных структурах данных (блокировка кэша); Этот механизм присутствует в процессорах Pentium 4, Intel Xeon и P6.

Эти механизмы взаимозависимы следующими способами. Определенные базовые транзакции памяти (такие как чтение или написание байта в системной памяти) всегда гарантированно обрабатываются атомно. То есть после начала процессор гарантирует, что операция будет завершена до того, как другой процессор или агент шины разрешит доступ к местоположению памяти. Процессор также поддерживает блокировку шин для выполнения выбранных операций памяти (например, операция с модификацией чтения-модификации в общей области памяти), которую обычно нужно обрабатывать атомно, но не обрабатывается автоматически таким образом. Поскольку часто используемые местоположения памяти часто кэшируются в кэшах L1 или L2 процессора, атомные операции часто можно выполнять внутри кэши процессора, не утверждая замок шины. Здесь протоколы когерентности кеша процессора гарантируют, что другие процессоры, которые кэшируют одни и те же места памяти, управляются должным образом, в то время как атомные операции выполняются в расположениях кэшированной памяти.

Answer 2

Нет. Из руководств IA32 (том 3A, глава 8.2: Упорядочение памяти):

Чтение или записи не может быть переупорядочено инструкциями ввода/вывода, Заблокированные инструкции, или сериализация инструкций.

Следовательно, инструкция по заблокированию не нужна с заблокированными инструкциями.

Answer 3

Проблема по-прежнему возникает, когда intel_lock1.c (доступен на URL выше) скомпилирована на Linux с GCC 5 или 7 без любого из Args '-d_with_cllush_' или '-d_with_hle_' (так что не используются ни Clflush*, ни Hle xacquire)-The Mutex_lock Assembler теперь выглядит как:

# 74 "intel_lock1.c" 1
    LFENCE
    lock subl   $1, lck(%rip)
    rep nop
    SFENCE

Итак, я пытаюсь заменить {l, s} забор с помощью Mfence.

Я до сих пор не совсем понимаю, как два потока могут получить одинаковое значение -1 *LCK, хотя.