Включает ли `xchg` в`mfence` отсутствие временных инструкций?
Я уже видел этот ответ и этот ответ, но ни один из них не дает четкого и ясного представления об эквивалентности или неэквивалентности mfence а также xchg при условии отсутствия временных инструкций.
Справочник по инструкции Intel для xchg упоминает, что эта инструкция полезна для реализации семафоров или аналогичных структур данных для синхронизации процессов, и дополнительно ссылается на главу 8 тома 3А. Эта ссылка гласит следующее.
Для процессоров семейства P6 заблокированные операции сериализуют все невыполненные операции загрузки и сохранения (то есть ожидают их завершения). Это правило также справедливо для процессоров Pentium 4 и Intel Xeon, за одним исключением. Операции загрузки, которые ссылаются на слабо упорядоченные типы памяти (например, тип памяти WC), могут быть не сериализованы.
mfence Документация утверждает следующее.
Выполняет сериализацию для всех команд загрузки из памяти и хранения в память, которые были выполнены до инструкции MFENCE. Эта операция сериализации гарантирует, что каждая инструкция загрузки и сохранения, которая предшествует инструкции MFENCE в программном порядке, становится видимой глобально перед любой инструкцией загрузки или сохранения, которая следует за инструкцией MFENCE. 1 Инструкция MFENCE упорядочена в отношении всех инструкций загрузки и хранения, других инструкций MFENCE, любых инструкций LFENCE и SFENCE и любых инструкций сериализации (таких как инструкция CPUID). MFENCE не сериализует поток команд.
Если мы игнорируем слабо упорядоченные типы памяти, делает ли xchg (что подразумевает lock ) охватывают все гарантии mfence в отношении упорядочения памяти?
1 ответ
Предполагая, что вы не пишете драйвер устройства (так что вся память для обратной записи, а не для слабо упорядоченной комбинации записи), тогда да xchg так же сильно, как mfence ,
NT магазины в порядке.
Я уверен, что это относится к текущему оборудованию, и уверен, что это гарантировано формулировками в руководствах для всех будущих процессоров x86. xchg это очень сильный полный барьер памяти.
Хм, я не смотрел на переупорядочение инструкций предварительной выборки. Это может иметь отношение к производительности или даже к правильности в странных ситуациях с драйверами устройств (когда вы используете кешируемую память, когда вам, вероятно, не следует).
Из вашей цитаты:
(P4 / Xeon) Операции загрузки, которые ссылаются на слабо упорядоченные типы памяти (например, тип памяти WC), могут быть не сериализованы.
Это единственное, что делает xchg [mem] слабее mfence (на Pentium4? Возможно также на семействе Sandybridge).
mfence действительно гарантирует, что именно поэтому Скайлэйк должен был укрепить это, чтобы исправить ошибку. ( Является ли загрузка и хранение единственными инструкциями, которые переупорядочиваются? А также ответом, на который вы ссылались. Поведение lock xchg такое же, как и у mfence?)
NT магазины сериализуются xchg / lock Это только слабо упорядоченные нагрузки, которые не могут быть сериализованы. Вы не можете делать слабо упорядоченные загрузки из памяти WB. movntdqa xmm, [mem] в WB память все еще строго упорядочена (и в текущих реализациях также игнорирует подсказку NT вместо того, чтобы что-либо делать для уменьшения загрязнения кэша).
Это выглядит как xchg работает лучше для магазинов seq-cst, чем mov + mfence на текущих процессорах, так что вы должны использовать это в обычном коде. (Вы не можете случайно отобразить память WC; нормальные ОС всегда будут предоставлять вам память WB для нормального распределения. WC используется только для видеопамяти или памяти другого устройства.)
Эти гарантии указаны в терминах конкретных семейств микроархитектур Intel. Было бы неплохо, если бы были какие-то общие "базовые x86" гарантии, которые мы могли бы принять для будущих процессоров Intel и AMD.
Я предполагаю, но не проверил, что xchg против mfence Ситуация такая же на AMD. Я уверен, что нет проблем с правильностью использования xchg как хранилище seq-cst, потому что это то, что на самом деле делают компиляторы, отличные от gcc.