Чем различаются порядки получения и потребления памяти и когда потребление предпочтительнее?

Упорядочивание зависимостей данных было введено N2492 со следующим обоснованием:

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

• доступ для чтения к редко записываемым параллельным структурам данных

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

• семантика публикации-подписки для публикации, опосредованной указателем

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

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

акцент мой

представлен мотивирующий вариант использования rcu_dereference() из ядра Linux

Потребление нагрузки во многом похоже на получение нагрузки, за исключением того, что оно вызывает отношения «происходит до» только для оценок выражений, которые зависят от данных при потреблении нагрузки. Заключение выражения в kill_dependency приводит к значению, которое больше не несет зависимости от нагрузки.

Ключевой вариант использования заключается в том, что писатель последовательно создает структуру данных, а затем передает общий указатель на новую структуру (используя атомарный release или acq_rel). Читатель использует загрузку для чтения указателя и разыменовывает его, чтобы перейти к структуре данных. Разыменование создает зависимость данных, поэтому читатель гарантированно увидит инициализированные данные.

std::atomic<int *> foo {nullptr};
std::atomic<int> bar;

void thread1()
{
    bar = 7;
    int * x = new int {51};
    foo.store(x, std::memory_order_release);
}

void thread2()
{
    int *y = foo.load(std::memory_order_consume)
    if (y)
    {
        assert(*y == 51); //succeeds
        // assert(bar == 7); //undefined behavior - could race with the store to bar 
        // assert(kill_dependency(*y) + bar == 58) // undefined behavior (same reason)
        assert(*y + bar == 58); // succeeds - evaluation of bar pulled into the dependency 
    }
}

Есть две причины для обеспечения нагрузки-потребления. Основная причина в том, что нагрузки ARM и Power гарантированно потребляют, но требуют дополнительных ограждений, чтобы превратить их в приобретаемые. (В x86 все нагрузки приобретаются, поэтому потребление не дает прямого преимущества в производительности при наивной компиляции.) Вторичная причина заключается в том, что компилятор может перемещать более поздние операции без зависимости от данных до момента потребления, чего он не может сделать для получения . (Включение такой оптимизации - большая причина для построения всего этого упорядочивания памяти в языке.)

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

Обратите внимание, что использование потребления приводит к тому, что отношение происходит раньше, которое больше не является транзитивным (хотя оно по-прежнему гарантированно является ациклическим). Например, сохранение в bar происходит перед сохранением в foo, что происходит перед разыменованием y, что происходит перед чтением bar (в закомментированном утверждении), но сохранение в bar не происходит до чтения из bar. Это приводит к довольно сложному определению «происходит до», но вы можете представить, как это работает (начните с последовательности «до», а затем распространите через любое количество ссылок «release-consumer-dataDependency» или «release-take-sequenceBefore»).

У Джеффа Прешинга есть отличный пост в блоге, отвечающий на этот вопрос. Сам я не могу ничего добавить, но думаю, что любой, кто интересуется потреблением и приобретением, должен прочитать его пост:

http://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/

Он показывает конкретный пример C ++ с соответствующим протестированным кодом сборки для трех разных архитектур. По сравнению с memory_order_acquire, memory_order_consume потенциально предлагает 3-кратное ускорение на PowerPC, 1,6-кратное ускорение на ARM и незначительное ускорение на x86, которое в любом случае имеет сильную согласованность. Загвоздка в том, что на момент написания только GCC фактически обрабатывал семантику потребления иначе, чем получение, и, вероятно, из-за ошибки. Тем не менее, это демонстрирует, что ускорение доступно, если разработчики компилятора могут выяснить, как этим воспользоваться.

Я хотел бы записать частичный вывод, хотя это не настоящий ответ и не означает, что за правильный ответ не будет большой награды.

Посмотрев какое-то время на 1.10 и, в частности, на очень полезную заметку в параграфе 11, я думаю, что это на самом деле не так уж и сложно. Большая разница между синхронизирует-с (далее: s / w) и dependency-order-before (dob) заключается в том, что происходит-до связь может быть установлена ​​путем произвольного объединения последовательность-перед (s / b) и s / w, но не так для dob. Обратите внимание, что одно из определений для межпотока происходит раньше:

A синхронизируется - с X и X упорядочивается до B

Но аналогичный оператор для A упорядочивается по зависимости до того, как X отсутствует!

Таким образом, с выпуском / получением (т.е. s / w) мы можем заказывать произвольные события:

A1    s/b    B1                                            Thread 1
                   s/w
                          C1    s/b    D1                  Thread 2

Но теперь рассмотрим произвольную последовательность событий, подобную этой:

A2    s/b    B2                                            Thread 1
                   dob
                          C2    s/b    D2                  Thread 2

В этом случае по-прежнему верно, что A2 происходит-раньше C2 (потому что A2 - это s / b B2, а B2 межпотоковое взаимодействие происходит раньше C2 из-за dob; но мы могли бы возразить, что вы никогда не сможете точно сказать!). Однако неверно, что A2 происходит раньше D2. События A2 и D2 не упорядочены относительно друг друга, если на самом деле не установлено, что C2 несет зависимость от D2. Это более строгое требование, и без этого требования A2-to-D2 не может быть заказано "по" паре "выпуск / потребление".

Другими словами, пара выпуск / потребление только распространяет порядок действий, которые несут зависимость от одного к другому. Все, что не является зависимым, не упорядочивается по паре выпуск / потребление.

Кроме того, обратите внимание, что порядок восстанавливается, если мы добавляем последнюю, более сильную пару выпуск / получение:

A2    s/b    B2                                                         Th 1
                   dob
                          C2    s/b    D2                               Th 2
                                             s/w
                                                    E2    s/b    F2     Th 3

Теперь, согласно указанному правилу, D2 межпоточное взаимодействие происходит до F2, и, следовательно, то же самое происходит с C2 и B2, и поэтому A2 происходит до F2. Но обратите внимание, что между A2 и D2 по-прежнему нет упорядочивания, это только между A2 и более поздними событиями.

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

Может быть, вот пример, который имеет смысл?

std::atomic<int> foo(0);

int x = 0;

void thread1()
{
    x = 51;
    foo.store(10, std::memory_order_release);
}

void thread2()
{
    if (foo.load(std::memory_order_acquire) == 10)
    {
        assert(x == 51);
    }
}

Как написано, код свободен от гонок, и утверждение останется в силе, потому что пара освобождение / получение упорядочивает хранилище x = 51 перед загрузкой в ​​утверждении. Однако, если изменить «приобретение» на «потребление», это больше не будет правдой, и программа будет иметь гонку данных на x, поскольку x = 51 не несет зависимости в хранилище от foo. Смысл оптимизации в том, что это хранилище можно свободно переупорядочивать, не обращая внимания на то, что делает foo, потому что здесь нет зависимости.