Понимание std:: atomic:: compare exchange weak() в C++11

зачем делать обмен в цикле?

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

обратите внимание, что также compare_exchange_strong часто используется в цикле. Он не терпит неудачу из-за ложного сбоя, но он терпит неудачу из-за одновременной записи.

зачем использовать weak вместо strong?

довольно легко: паразитный отказ не делает случаются часто, так что это не большой хит производительности. В constrast, терпеть такой отказ позволяет для гораздо более эффективной реализации weak версия (по сравнению с strong) на некоторых платформах: strong необходимо всегда проверять наличие ложного отказа и маскировать его. Это дорого стоит.

таким образом, weak используется, потому что это намного быстрее, чем strong на некоторых платформах

когда следует использовать weak и когда strong?

в ссылка состояния подсказывает, когда использовать weak и когда использовать strong:

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

таким образом, ответ кажется довольно простым для запоминания: Если вам придется вводить цикл только из-за ложного отказа, не делайте этого; используйте strong. Если у вас есть цикл в любом случае, то используйте weak.

почему

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

это просто быстрый путь, когда другое нить пишет true: тогда мы прерываем вместо того, чтобы пытаться написать true снова.

о вашем последнем вопросе

но как было проанализировано выше, две версии в цикле должны давать одинаковую / аналогичную производительность. Чего мне не хватает?

С Википедия:

реальные реализации LL / SC не всегда успешны, если их нет одновременное обновление соответствующей области памяти. Каких-либо исключительных события между двумя операциями, например переключение контекста, другой load-link, или даже (на многих платформах) другой груз или магазин операция, приведет к тому, что хранилище-условное ложно выйдет из строя. Более старый реализация будет выполнена, если есть какие-либо обновления, распространяемые шина памяти.

Итак, LL/SC не будет ложно на контекст переключатель, например. Теперь сильная версия принесет свой "собственный небольшой цикл", чтобы обнаружить этот ложный сбой и замаскировать его, попытавшись снова. Обратите внимание, что этот собственный цикл также сложнее, чем обычный цикл CAS, поскольку он должен различать ложную ошибку (и маскировать ее) и сбой из-за параллельного доступа (что приводит к возврату со значением false). Слабая версия не имеет такого собственного цикла.

после явного цикла в обоих примерах, это просто не необходимо иметь небольшой цикл для сильной версии. Следовательно, в Примере с strong версия, проверка на отказ выполняется дважды; один раз compare_exchange_strong (что более сложно, так как он должен различать ложные сбои и параллельные доступы) и один раз по вашему циклу. Эта дорогая проверка не нужна и причина, почему weak здесь будет быстрее.

также обратите внимание, что ваш аргумент (LL / SC) просто один возможность реализовать это. Есть и другие платформы, которые имеют даже различные наборы инструкций. Кроме того (и что более важно), обратите внимание, что std::atomic должны поддерживать все операции на все возможные типы данных, поэтому даже если вы объявите десятимиллионную структуру байтов, вы можете использовать compare_exchange об этом. Даже когда на процессоре, который имеет CAS, вы не можете CAS десять миллионов байт, поэтому компилятор будет генерировать другие инструкции (вероятно, lock acquire, а затем неатомное сравнение и обмен, а затем освобождение блокировки). Теперь, подумайте о сколько всего может произойти при обмене десятью миллионами байт. Таким образом, хотя ложная ошибка может быть очень редкой для 8-байтовых обменов, в этом случае она может быть более распространенной.

Итак, в двух словах, C++ дает вам две семантики, "лучшее усилие" (weak) и "я сделаю это наверняка, независимо от того, сколько плохих вещей может произойти между ними" (strong). Как они реализуются на различных типах данных и платформах-это совершенно другая тема. Не привязывайте свою ментальную модель к реализация на вашей конкретной платформе; стандартная библиотека предназначена для работы с большим количеством архитектур, чем вы могли бы знать. Единственный общий вывод, который мы можем сделать, заключается в том, что гарантировать успех обычно сложнее (и, следовательно, может потребовать дополнительной работы), чем просто пытаться и оставлять место для возможного провала.

почему это должно быть в цикле в почти все использует ?

потому что, если вы не зацикливаетесь, и он не работает ложно, ваша программа не сделала ничего полезного - вы не обновили атомарный объект, и вы не знаете, какое его текущее значение (исправление: см. комментарий ниже от Cameron). Если вызов не делает ничего полезного, какой смысл делать это?

означает ли это, что мы будем цикл, когда он не работает из-за паразитных неудачи?

да.

если это так, почему мы беспокоимся использовать compare_exchange_weak() и написать цикл сами? Мы можем просто использовать compare_exchange_strong (), который я думаю, должен избавиться от ложных сбоев для нас. Каковы общие случаи использования compare_exchange_weak ()?

на некоторых архитектурах compare_exchange_weak является более эффективным, и паразитные сбои должны быть довольно редкими, поэтому можно было бы написать более эффективные алгоритмы с использованием слабая форма и петля.

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

почему !expected там в состоянии цикла?

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

Edit:

но как было проанализировано выше, две версии в цикле должны давать одинаковую / аналогичную производительность. Чего мне не хватает?

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

слабая форма просто возвращается при ложном сбое,он не повторяется.

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

void atomicLeftShift(std::atomic<int>* var, int shiftBy)
{
    do {
        int oldVal = std::atomic_load(var);
        int newVal = oldVal << shiftBy;
    } while(!std::compare_exchange_weak(oldVal, newVal));
}

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

1. кто-то еще изменил переменную, пока я делал свой левый сдвиг. Результаты моих вычислений не должны применяться к атомарному переменная, потому что она будет эффективно стирать эту чужую запись.
2. мой процессор рыгнул, и слабый CAS ложно провалился.

честно говоря, мне все равно, какой из них. Левый сдвиг достаточно быстр, чтобы я мог просто сделать это снова, даже если сбой был ложным.

что это меньше быстрый, однако, это дополнительный код, который сильный CAS должен обернуть вокруг слабого CAS, чтобы быть сильным. Этот код не делает много, когда слабый CAS преуспевает... но когда это не удается, сильный CAS должен сделать некоторую детективную работу, чтобы определить, был ли это случай 1 или Случай 2. Эта детективная работа принимает форму второй петли, фактически внутри моей собственной петли. Два вложенных цикла. Представьте, что ваш учитель алгоритмов смотрит на вас прямо сейчас.

и как я уже упоминал ранее, меня не волнует результат этой детективной работы! В любом случае я собираюсь переделать CAS. Поэтому использование сильного CAS не приносит мне ровно ничего, и теряет меня немного но измеримое количество эффективности.

другими словами, слабый CAS используется для реализации атомарных операций обновления. Сильный CAS используется, когда вы заботитесь о результате CAS.