В каких случаях необходимо использовать atomic_compare_exchange_weak, а в каких atomic_compare_exchange_strong?
http://en.cppreference.com/w/cpp/atomic/atomic_compare_exchange

авторWhen a compare-and-exchange is in a loop, the weak version will yield better performance on some platforms. When a weak compare-and-exchange would require a loop and a strong one would not, the strong one is preferable.

Если по русски, то когда compare-and-exchange в цикле, то лучше weak. А когда weak может потребовать цикл, а strong не потребует, то лучше strong.
Вопрос, а когда такой случай может быть в реальности?

Например: std::atomic | compare_exchange_weak vs. compare_exchange_strong
авторAs such, an LL/SC pair is stronger than a read followed by a compare-and-swap ( CAS ), which will not detect updates if the old value has been restored (see ABA problem ).
Я правильно понял, что здесь пишут о том, что weak может выдать false если сравниваемые значения равны, но была замена по типу ABA, т.е. изменение было, но в конце заменили на то же значение?

Хорошо, т.е. мы с помощью weak можем решать проблему ABA и вообще weak имеет смысл только для ABA?

Но во-первых требуется LL/SC , которые есть только в: DEC Alpha, MIPS, PowerPC and ARM (v6 and later).
Т.е. на фига такое решение ABA, когда на одних процессорах оно работает, а на других нет (например x86)?

А во-вторых там же в http://en.wikipedia.org/wiki/ABA_problem пишут:
авторExamples include DEC Alpha, MIPS, PowerPC and ARM (v6 and later). However no practical implementations of load linked will directly solve the ABA problem . [Michael]
Спрашивается, на кой нужен weak и чем он лучше, за исключением ABA - которую он где-то решает, а где-то и не решает, а там где решает эту случаи и не известны?

_Прохожий_LL/SC это 2 команды процессора между которыми заключено произвольное количество команд. LL(Load-Link) вытаскивает данные в контролируемое хранилище, SC(Store-Conditional) аппаратно гарантирует ошибку при попытке записать эти "защищенные" данные, если они изменялись после выполнения LL, независимо от значения в них. Т.е. ошибка будет и в случае если операнд LL был равен 1, потом изменен на 0 и к моменту выполнения SC снова стал равен 1.
От ABA LL/SC защищает только если вы часть своего алгоритма, связанную с выборкой данных и их модификацией помещаете между LL и SC.

При эмуляции CAS с помощью LL/SC, т.е. в atomic_compare_exchange никакой защиты от ABA нет.
Ну тогда тем более вопрос, зачем нужен weak если он не решает никаких проблем, а может только ложно давать false и лишний раз пускать по циклу?

_Прохожий_Сугубое ИМХО:

В случае LL/SC может вернуть false, если значение флага не изменилось в CAS, но он тем не менее менялся, т.к. связка LL/SC выполняется процессором не атомарно. Т.е. локальная ABA случилась внутри CAS, а не внутри какого-то lock-free алгоритма.
На x86 CAS операция будет выполнена атомарно, никто 100% не сможет изменить флаг при выполнении например LOCK CMPXCHG.
Внутри LL/SC это возможно.
Спасибо, это было понятно и из предыдущего вашего сообщения :) Это подтверждает, что weak не имеет смысла.
А CAS на x86 бывает без LOCK?

Anatoly Moskovskyweak vs strongА CAS на x86 бывает без LOCK?
Конечно бывает, не атомарный :)
Я имею ввиду может ли atomic_compare_exchange_weak скомпилироваться во что-то отличное от блокирующего CMPXCHG? :)

http://david.jobet.free.fr/wiclear-blog/?fr/2010-10-17-c -atomic-lib-impl-rules
авторThere is no compare exchange "weak" operation on x86. It is equivalent to a compare exchange "strong" operation.

In the standard, the difference is that it allows it to fails spuriously. I guess this is to allow implementation using LL/SC instead of a CAS.
По крайней мере я теперь знаю, что на x86 нет разницы между weak и strong, но нафига нужен weak на других платформах - большая загадка.

_Прохожий_На x86 без разницы, там внутри CAS не может ничего случится отличного в обоих вариантах, для процессоров с LL/SC возможны варианты реализации с weak и strong. Правда я бы не рискнул отдавать это на откуп их реализации в библиотеках.

Что касается атомарности, то CMPXCHG без LOCK тоже атомарна на 100%, LOCK заставляет отреагировать кэш другого процессора.
Важна не только атомарность команды процессора, на середине выполнения INC, ADD и т.д. x86 тоже не прерывается.
Да, пока что из доступной информации: в x86 нет разницы weak/strong, для LL/SC есть разница, weak всегда хуже чем strong и weak никогда не имеет смысла :)

То что XCHG всегда эквивалентно LOCK XCHG, а CMPXCHG отличается от LOCK CMPXCHG - понятно, но в какую из них должно скомпилироваться atomic_compare_exchange_weak с relaxed, в CMPXCHG или LOCK CMPXCHG на x86?

Anatoly Moskovsky_Прохожий_Что касается атомарности, то CMPXCHG без LOCK тоже атомарна на 100%, LOCK заставляет отреагировать кэш другого процессора.
Атомарность в пределах одного процессора никому не нужна.
А для многопроцессорных - без lock ни про какую атомарность речь не идет.
Здесь важно добавить, что это "без lock ни про какую атомарность речь не идет" - справедливо только для CAS?
Потому, что у atomic<>::load() и atomic<>::store() на x86 (за исключением std::memory_order_seq_cst) все замечательно атомарно разруливается на уровне когерентности кэшей без всяких LOCK, обычными mov-ами.

Anatoly Moskovskyweak vs strong,

Да, там где чтение и запись в одном примитиве.
А не могли бы ссылку дать на что-нибудь авторитетное, где говориться, что CAS на x86 без LOCK не бывает и всегда LOCK CMPXCHG?

По логике то я понимю, что CISC-овая CMPXCHG в x86 транслируется в 3 RISC-овые команды: загрузки, сравнения и сохранения, которые кстати происходят в любом случае, и по этому без блокировки шины(LOCK) просто гарантированно портили бы данные своим сохранением при любом конкурентном доступе:
CAS
автор3. Если значение в памяти было равно значению в аккумуляторе, процессор записывает значение из второго операнда в область памяти, указанную первым операндом. (Особенность реализации x86: запись происходит всегда , но если сравнение на шаге 2 показало неравенство, записывается то значение, что было прочтено из памяти на шаге 1.)

Ну и общий вывод, что CAS-ов на x86 надо избегать, т.к. блокируют весь кэш эXклюзивной блокировкой, в отличие от mov, который блокирует только одну кэш линию (и причем не обязательно эXклюзивной блокировкой).