Как выразить в С++ 11 обычные хранилища (экспорт) и загрузки (импорт) барьеры (заборы)?

Согласно статье о порядке_памяти, чтобы быть консервативно безопасным, вам нужно использовать memory_order_release после хранилище и memory_order_acquire перед загрузкой (оба одной и той же атомарной переменной).

So:

 std::atomic<int> var;

 // Writer
 // something important <happens-before> writing 42 in the writer thread
 var.store(42, std::std::memory_order_release);

 // Reader
 auto result = var.load(std::std::memory_order_acquire);
 if (result == 42) {
    // transitively, as the result's new value is observed, the "something important" is here too
 }

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

Как правило, вы предпочитаете std::atomic_flag вместо std::atomic<bool>, так как первый гарантированно будет заблокирован -бесплатно, в отличие от последнего.

Наконец, почему бы не начать с критической секции, защищенной мьютексом, или, что еще лучше, не отправить обновления потребителю через кольцевой буфер без блокировок, чтобы они ничего не делили?

Ниже вы найдете гораздо более полезный пример:

Позвольте мне повторить, что вы по существу делаете.

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

С++ не позволяет вам это сделать.

Если вы читаете из неатомарного объекта, который потенциально может быть записан каким-то другим потоком, без надлежащего выполнения и синхронизации памяти между двумя операциями, то у вас есть гонка данных. Наличие гонки данных не означает, что вы можете считать неверные значения; это означает, что ваш код имеет неопределенное поведение.

Вы не можете отменить УБ. Как только ваша программа входит в зону неопределенного поведения, все ставки сняты. По крайней мере, что касается стандарта.

Конечно, вы можете переписать свой код, чтобы он работал в рамках стандарта. Но он должен предотвращать выполнение чтения, пока может происходить запись, а не просто проверять постфактум, чтобы убедиться, что чтение в порядке. Если размер записи всегда составляет 1 КБ, для функции записи, вероятно, подойдет спин-блокировка на основе атомарных данных, и читатель может просто вернуть -1, если атомарная блокировка недоступна.

Вы также можете написать такую ​​систему (по-видимому, называемую "SeqLock"), используя C++ atomics, с полным пониманием того, что он вызывает UB в отношении стандарта. Пока типы, которые вы копируете, тривиальны, все будет работать нормально.

Обратите внимание, что C++ Concurrency TS 2 будет включать функцию, позволяющую реализовывать SeqLock. Мы надеемся увидеть полный стандарт C++23.

Ваш пример правильный. Я не думаю, что стандарт очень ясен, когда дело доходит до того, как обрабатываются неатомарные объекты.

std::atomic<bool> valid{true};           // removed volatile
uint8_t blob[1024] = {/*some values*/};  // removed volatile

void zero_blob() {
    valid.store(false, std::memory_order_relaxed);            // A)
    std::atomic_thread_fence(std::memory_order_release);      // B)
    memset(blob,0,1024);                                      // C)
}                                                              

int32_t try_get_sum(size_t index_1, size_t index_2) {          
    uint8_t res = blob[index_1] + blob[index_2];              // D)
    std::atomic_thread_fence(std::memory_order_acquire);      // E)
    return valid.load(std::memory_order_relaxed) ? res : -1;  // F)
}

Забор на шаге B) гарантирует, что порядок программы будет соблюдаться, и стандарт на самом деле не говорит об этом, но сохранение в valid должно распространяться перед любой последующей записью в том же потоке.

Забор на шаге E) гарантирует соблюдение порядка выполнения программы.

Таким образом, A) межпотоковое взаимодействие происходит раньше, чем C) и D) происходит раньше, чем F)

Если F) воспринимает, что valid является true, тогда, при условии отсутствия проблемы ABA, F) происходит раньше, чем A).

Если F) происходит раньше, чем A), то D) происходит раньше, чем A).

Если F воспринимает, что valid есть false, то A) происходит раньше F). Это не обязательно означает, что C) происходит раньше D), но на всякий случай мы отбрасываем результат. Это действительно важно отбросить, потому что значения в blob могут быть совершенно недействительными. (Хотя использование uint8_t защищает от частичного чтения при преобразовании в void*. Он выровнен по кешу, но технически не имеет размера слова, что ставит под сомнение атомарность. IIRC теоретически также может быть уязвим для истинного частичного чтения на некоторых маловероятных архитектурах. .)

Эти выводы основаны на модели согласованности памяти ядра Linux (LKMM), а не на модели памяти C++. Из того, что я прочитал на cppreference.com, когда они говорят о порядке распространения в модели памяти C++, они используют такие фразы, как «все изменения до X в потоке A будут видны после Y в потоке B», но обычно только в контекст атомарных операций. Я думаю, что ожидать, что компилятор C++ будет выдавать инструкции, гарантирующие порядок распространения, относительно мало рискованно, по крайней мере, на процессорах потребительского уровня. Вы все равно должны проверить сборку и свериться с документацией по процессору. Вы определенно будете в порядке на x86 благодаря TSO, но я никогда не смотрел, какие примитивы порядка распространения доступны в слабоупорядоченных архитектурах.

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