как барьеры / ограждения и семантика приобретения и выпуска реализованы микроархитектурно?

Многое из этого было рассмотрено в других вопросах и ответах, но здесь я дам краткое изложение. (И ищите ссылки для добавления). Тем не менее, хороший вопрос, полезно все это собрать в одном месте.

На x86 каждая загрузка asm является загрузкой-получателем. Чтобы реализовать это эффективно, современное аппаратное обеспечение x86 предположительно загружается раньше, чем разрешено, а затем проверяет это предположение. (Это может привести к сбою в конвейере неверного определения порядка памяти.) Чтобы отследить это, Intel называет комбинацию буферов загрузки и хранения «Буфером порядка памяти».

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

Порядок хранилищ x86 поддерживается только за счет разрешения хранилищам фиксироваться из буфера хранилища в L1d в программном порядке.

По крайней мере, на процессорах Intel запись буфера хранилища выделяется для хранилища, когда оно выдает (из внешнего интерфейса в ROB + RS). Для всех мопов должна быть выделена запись ROB, но некоторым мопам также необходимо выделить другие ресурсы, такие как загрузка или сохранение записей буфера, записи RAT для регистров, которые они читают / записывают, и так далее.

Итак, я думаю, что сам буфер хранилища упорядочен. Когда выполняется uop-адрес хранилища или хранилище данных, он просто записывает адрес или данные в свою уже выделенную запись буфера хранилища. Поскольку фиксация (освобождение записей SB) и выделение выполняются в программном порядке, я предполагаю, что физически это кольцевой буфер с головой и хвостом, как ROB. (И в отличие от RS).

Отказ от LoadStore в основном бесплатен: загрузка не может быть удалена, пока она не будет выполнена (данные взяты из кеша). Магазин не может выполнить фиксацию до после его закрытия. Списание по порядку автоматически означает, что все предыдущие загрузки выполняются до того, как магазин будет «завершен» и готов к фиксации.

Слабо упорядоченный uarch, который на практике может выполнять переупорядочивание загрузки-хранилища, может вести счет загрузки: пусть они удаляются, если они не исправны, но до того, как поступят данные.

Это кажется более вероятным на работающем ядре, но не на IDK. Таким образом, у вас может быть нагрузка, которая удалена, но адресат регистра все равно остановится, если что-то попытается прочитать его до того, как данные действительно поступят. Мы знаем, что упорядоченные ядра на практике работают таким образом, не требуя завершения загрузки перед выполнением последующих инструкций. (Вот почему программная конвейерная обработка с использованием большого количества регистров так важна для таких ядер, например, для реализации memcpy. Немедленное чтение результата загрузки на упорядоченном ядре разрушает параллелизм памяти.)

Как load- ›переупорядочивание магазина возможно с помощью in-order commit? рассматривает этот вопрос более глубоко, чтобы определить порядок и нарушение порядка.

Барьерные инструкции

Единственная инструкция барьера, которая что-либо делает для обычных хранилищ, - это mfence, которая на практике останавливает операции с памятью (или весь конвейер) до тех пор, пока буфер хранилища не будет опустошен. Загружаются и сохраняются единственные инструкции, которые переупорядочиваются? охватывает поведение Skylake-with-updated-microcode, которое также действует как lfence.

lfence в основном существует из-за микроархитектурного эффекта, заключающегося в блокировании более поздних инструкций даже от выдачи до тех пор, пока все предыдущие инструкции не выйдут из неупорядоченного внутреннего интерфейса (сняты с производства). Вариантов использования упорядочивания памяти lfence fo практически не существует.

связанные с:

• Сколько инструкций по ограничению памяти имеет процессор x86? < / а>
• Как я могу испытать LFENCE или SFENCE не может пройти ранее чтение / запись
• Блокировка xchg ведет себя так же, как mfence?
• Делает ли модель памяти Intel избыточность SFENCE и LFENCE? < / а>
• Понимание влияния lfence на цикле с двумя длинными цепочками зависимостей для увеличения длины подробно рассказывает о том, как LFENCE останавливает выполнение последующих инструкций и что это означает для производительности.
• Когда следует использовать _mm_sfence _mm_lfence и _mm_mfence языки высокого уровня имеют более слабые модели памяти, чем x86, поэтому иногда вам нужен только барьер, который не компилирует инструкции asm. Использование _mm_sfence(), когда вы не использовали никаких хранилищ NT, просто делает ваш код медленнее без причины, чем atomic_thread_fence(mo_release).