Почему SFENCE + LFENCE эквивалентно (или нет?) MFENCE?

Инструкции по ограждению x86 можно кратко описать следующим образом:

• MFENCE предотвращает глобальное наблюдение за любой последующей загрузкой или сохранением перед любой более ранней загрузкой или сохранением. Он истощает буфер хранилища перед тем, как более поздние загрузки ¹ могут выполнить.

• LFENCE блокирует отправку инструкций (по терминологии Intel) до тех пор, пока не будут удалены все предыдущие инструкции. В настоящее время это реализуется путем осушения ROB (буфера повторного заказа) до того, как последующие инструкции смогут передать в серверную часть.

• SFENCE упорядочивает хранилища только по отношению к другим хранилищам, то есть предотвращает фиксацию хранилищ NT из буфера хранилища перед самой SFENCE. Но в остальном SFENCE похожа на обычное хранилище, которое перемещается через буфер хранилища. Думайте об этом, как о том, как поставить разделитель на конвейерную ленту кассового магазина в продуктовом магазине, который не дает магазинам NT забираться раньше времени. Это не обязательно принудительно очищает буфер хранилища до того, как он удалится из ROB, поэтому установка LFENCE после этого не дает в сумме MFENCE.

• Команда сериализации, такая как CPUID (и IRET и т. Д.), Истощает все (ROB, буфер хранилища) до того, как последующие инструкции могут быть переданы в серверную часть. MFENCE + LFENCE также сделает это, но настоящие инструкции сериализации могут иметь и другие эффекты, я не знаю.

Эти описания немного неоднозначны с точки зрения того, какие именно операции заказываются, и есть некоторые различия между поставщиками (например, SFENCE сильнее на AMD) и даже процессорами от одного поставщика. Обратитесь к руководству Intel и обновлениям спецификаций, а также к руководству AMD и руководствам по версиям для получения дополнительной информации. Есть также много других обсуждений этих инструкций в других местах. Но сначала прочтите официальные источники. Приведенные выше описания, я думаю, являются минимальным указанным на бумаге поведением поставщиков.

Сноска 1: OoO exec более поздних хранилищ не нужно блокировать с помощью MFENCE; их выполнение просто записывает данные в буфер хранилища. Фиксация по порядку уже заказывает их после предыдущих магазинов и фиксирует после списания заказов. загружает (потому что x86 требует, чтобы загрузка была завершена, а не только началась, прежде чем они могут быть отключены, как часть обеспечения порядка загрузки). Помните, что оборудование x86 построено так, чтобы запрещать переупорядочивание, отличное от StoreLoad.

В руководстве Intel, том 2, номер 325383-072US, SFENCE описывается как инструкция, которая гарантирует, что каждое хранилище до SFENCE будет глобально видимым до того, как любое хранилище после SFENCE станет глобально видимым. Раздел 11.10 тома 3 говорит, что буфер хранилища опустошается при использовании SFENCE. Правильная интерпретация этого утверждения - это в точности предыдущее утверждение из тома 2. Таким образом, можно сказать, что SFENCE истощает буфер хранилища в этом смысле. Нет гарантии, в какой момент в течение жизненного цикла SFENCE более ранние магазины достигнут GO. Для любого более раннего магазина это могло произойти до, во время или после прекращения работы SFENCE. Что касается смысла GO, это зависит от нескольких факторов. Это выходит за рамки вопроса. См .: Почему «movnti», за которым следует «sfence», гарантирует постоянное заказ？.

MFENCE действительно должен предотвращать переупорядочивание хранилищ NT с другими хранилищами, поэтому он должен включать все, что делает SFENCE, а также очищать буфер хранилища. А также переупорядочение слабо упорядоченных загрузок SSE4.1 NT из памяти WC, что сложнее, потому что обычные правила, которые получают бесплатный порядок загрузки, к ним больше не применяются. Гарантия этого - вот почему обновление микрокода Skylake усилило (и замедлило) MFENCE., чтобы слить ROB как LFENCE. MFENCE все еще может иметь меньший вес, чем аппарат с поддержкой HW для необязательно принудительного упорядочивания NT-нагрузок в конвейере.

Основная причина, по которой SFENCE + LFENCE не равно MFENCE, заключается в том, что SFENCE + LFENCE не блокирует переупорядочение StoreLoad, поэтому этого недостаточно для последовательной согласованности. Только mfence (или операция locked, или настоящая инструкция сериализации, такая как cpuid) сделает это. См. переупорядочение памяти, обнаруженное в действии Джеффа Прешинга, чтобы узнать случай, когда достаточно только полного барьера.

Из справочного руководства Intel для sfence:

Процессор гарантирует, что каждое хранилище до SFENCE будет глобально видимым до того, как любое хранилище после SFENCE станет глобально видимым.

но

Он не упорядочен по загрузке памяти или инструкции LFENCE.

LFENCE заставляет более ранние инструкции выполняться локально (т. Е. Удаляться из вышедшей из строя части ядра), но для хранилища или SFENCE это просто означает размещение данных или маркера в буфере порядка памяти, а не его очистку, поэтому хранилище становится видимым во всем мире. т.е. завершение SFENCE (вывод из ROB) не включает очистку буфера хранилища.

Это похоже на описание Preshing в Барьеры памяти похожи на операции управления исходным кодом., где препятствия StoreStore не возникают мгновенно. Позже в этой статье он объясняет, почему барьер #StoreStore + #LoadLoad + #LoadStore не суммируется с барьером #StoreLoad. (x86 LFENCE имеет некоторую дополнительную сериализацию потока инструкций, но, поскольку он не очищает буфер хранилища, рассуждения все еще остаются в силе).

LFENCE не полностью сериализуется, как cpuid ( который является таким же сильным барьером памяти, как mfence или locked инструкция). Это просто барьер LoadLoad + LoadStore плюс некоторые вещи сериализации выполнения, которые, возможно, начинались как деталь реализации, но теперь закреплены в качестве гарантии, по крайней мере, для процессоров Intel. Это полезно с rdtsc, а также для предотвращения спекуляций ветвями для смягчения последствий Spectre.

Кстати, SFENCE не работает для магазинов WB (обычных).

Он упорядочивает хранилища WC (например, movnt или записи в видеопамять) в отношении любых хранилищ, но не в отношении нагрузок или LFENCE. Только на ЦП, который обычно слабо упорядочен, барьер магазин-магазин делает что-нибудь для обычных магазинов. Вам не понадобится SFENCE, если вы не используете хранилища NT или область памяти, отображаемую в WC. Если бы он гарантировал очистку буфера хранилища до его выхода из эксплуатации, вы могли бы построить MFENCE из SFENCE + LFENCE, но это не относится к Intel.

Реальная проблема заключается в переупорядочивании StoreLoad между магазином и грузом, а не между магазином и барьерами, поэтому вам следует посмотреть на случай с магазином, затем барьер, затем груз.

mov  [var1], eax
sfence
lfence
mov   eax, [var2]

может стать глобально видимым (т. е. зафиксировать в кэше L1d) в следующем порядке:

lfence
mov   eax, [var2]     ; load stays after LFENCE

mov  [var1], eax      ; store becomes globally visible before SFENCE
sfence                ; can reorder with LFENCE

В общем случае MFENCE! = SFENCE + LFENCE. Например, приведенный ниже код при компиляции с -DBROKEN дает сбой в некоторых системах Westmere и Sandy Bridge, но, похоже, работает на Ryzen. Фактически, в системах AMD достаточно просто SFENCE.

#include <atomic>
#include <thread>
#include <vector>
#include <iostream>
using namespace std;

#define ITERATIONS (10000000)
class minircu {
        public:
                minircu() : rv_(0), wv_(0) {}
                class lock_guard {
                        minircu& _r;
                        const std::size_t _id;
                        public:
                        lock_guard(minircu& r, std::size_t id) : _r(r), _id(id) { _r.rlock(_id); }
                        ~lock_guard() { _r.runlock(_id); }
                };
                void synchronize() {
                        wv_.store(-1, std::memory_order_seq_cst);
                        while(rv_.load(std::memory_order_relaxed) & wv_.load(std::memory_order_acquire));
                }
        private:
                void rlock(std::size_t id) {
                        rab_[id].store(1, std::memory_order_relaxed);
#ifndef BROKEN
                        __asm__ __volatile__ ("mfence;" : : : "memory");
#else
                        __asm__ __volatile__ ("sfence; lfence;" : : : "memory");
#endif
                }
                void runlock(std::size_t id) {
                        rab_[id].store(0, std::memory_order_release);
                        wab_[id].store(0, std::memory_order_release);
                }
                union alignas(64) {
                        std::atomic<uint64_t>           rv_;
                        std::atomic<unsigned char>      rab_[8];
                };
                union alignas(8) {
                        std::atomic<uint64_t>           wv_;
                        std::atomic<unsigned char>      wab_[8];
                };
};

minircu r;

std::atomic<int> shared_values[2];
std::atomic<std::atomic<int>*> pvalue(shared_values);
std::atomic<uint64_t> total(0);

void r_thread(std::size_t id) {
    uint64_t subtotal = 0;
    for(size_t i = 0; i < ITERATIONS; ++i) {
                minircu::lock_guard l(r, id);
                subtotal += (*pvalue).load(memory_order_acquire);
    }
    total += subtotal;
}

void wr_thread() {
    for (size_t i = 1; i < (ITERATIONS/10); ++i) {
                std::atomic<int>* o = pvalue.load(memory_order_relaxed);
                std::atomic<int>* p = shared_values + i % 2;
                p->store(1, memory_order_release);
                pvalue.store(p, memory_order_release);

                r.synchronize();
                o->store(0, memory_order_relaxed); // should not be visible to readers
    }
}

int main(int argc, char* argv[]) {
    std::vector<std::thread> vec_thread;
    shared_values[0] = shared_values[1] = 1;
    std::size_t readers = (argc > 1) ? ::atoi(argv[1]) : 8;
    if (readers > 8) {
        std::cout << "maximum number of readers is " << 8 << std::endl; return 0;
    } else
        std::cout << readers << " readers" << std::endl;

    vec_thread.emplace_back( [=]() { wr_thread(); } );
    for(size_t i = 0; i < readers; ++i)
        vec_thread.emplace_back( [=]() { r_thread(i); } );
    for(auto &i: vec_thread) i.join();

    std::cout << "total = " << total << ", expecting " << readers * ITERATIONS << std::endl;
    return 0;
}

Какой механизм отключает LFENCE, чтобы сделать невозможным переупорядочение (x86 не имеет механизма - Invalidate-Queue)?

Из документации Intel, том 2A, стр. 3-464, LFENCE инструкция:

LFENCE не выполняется до тех пор, пока все предыдущие инструкции не будут выполнены локально, и никакая последующая инструкция не начнет выполнение, пока LFENCE не завершится.

Итак, да, в вашем примере переупорядочение явно запрещено инструкцией LFENCE. Ваш второй пример, включающий только SFENCE инструкции, ЯВЛЯЕТСЯ допустимым переупорядочением, поскольку SFENCE не влияет на операции загрузки.