:( Но все равно, спасибо что помог бы, если б не телефон :)

Может народ подтянется кто вчера обсуждал и напишут все!

Нужно сразу очень вежливо призывать @shipilev 😊

Я призываю святые земли Хема, что лежат за востоком. Приветствую тебя, @shipilev , живительная кровь Хема, правитель водных путей. Я молюсь, чтобы ты обитал среди нас, в этом твоем храме.
Призыв выполнен, да.

Неожиданное утверждение. Есть ли ссылки на тесты?

Да, когда буду не с телефона, найду. Или воспользуйтесь системой поиска Google.

Будут те же гарантии, как и в случае если запись release.
Т.е. если acq чтение прочитает из seq_cst, то между ними произойдёт синхронизация. В общем случае seq_cst даёт все те же гарантии, что и rel/acq плюс ещё доп. гарантии, которые я не берусь объяснять.

ну, то есть. У нас в каком то потоке может произойти запись с seq_cst, в переменную, а в другом потоке произойдет ее чтение, acq, но этот поток НЕ гарантированно прочтет то, что наизменял тот, кто записывал?

Да, конечно

merci, бэкап!

Ну даже если у вас и запись и чтение будут seq_cst, может случиться так, что чтение "произойдёт до" записи и не увидит её .

ну в этом случае то ясно, но я же про случай запись 'до' чтения.

при сек каст чтении в таком случае, все ок будет, гарантированно.

Да

Что конкретно искать? Поискал lock-free is slow, нашёл только общие слова. Когда мерял для себя, lock-free структуры были всегда быстрее семафоров или мьютексов. Понятно, что они подходят и для других сценариев, типа инверсии приоритетов. Но я бы сказал, что если в системе возникает инверсия приоритетов, то что-то не так с системой, и её необходимо перерабатывать, а не маскировать проблему lock-free структурами.

ага, а вот при acq чтении, после записи, то, что я выше писал. Ну это я так, для уточнения. Окей. Спасибище.

Да, все так

Спасибо.

Как не стоит мешать водку с пивом, так и не стоит мешать seqcst с acq/rel! Но выше правильно заметили, что seqcst часто предполагает acq/rel (в Java и C++ это можно формально показать).