гарантирует то же что и acquire/release + дополнительные гарантии того что seq_cst доступ не переупорядоточен с другими доступами к памяти вокруг.
Как только вы начинаете миксовать sequentially consistent модель с acquire/release, стандарт говорит что "sequentially consistent" - не гарантируется, вы просто сьезжаете на acquire/release модель.
То есть, в оригинальном вопросе (он такой ?): https://godbolt.org/z/7sqaXk std::exit() гарантированно никогда не сработает:
если ready_ == 1 (acquire), то v_ == 42.
Естественно, чтение ready_ флага нужно делать как минимум всегда с acquire семанитикой чтобы сказанное выше соблюдалось.
(То что сказал Max выше).
Это, по сути, то же что и вы написали: "*когда* другое ядро увидит изменение атомика, оно так же увидит и все изменения идущие перед изменением атомика".
По поводу hazard pointer примера, немного непонятно, на RMW тоже навешивается memory_order.
Нужно смотреть конкретный пример.
В общем, насколько я понимаю, такое https://godbolt.org/z/7sqaXk поведение гарантировано стандартом.
интересная тема :) я тоже думаю, что на практике в твоем примере std::exit не вызовется. seq_cst более строгая гарантия. в скомпиленном примере там вкорячем mfence, что логично. Но вот действительно ли можно seq_cst миксовать? если да, то когда и зачем? :) btw, я открыл последний драфт и там вот (n4842, пункт 31.4 -> (4.4) ): 6 [Note: We do not require that S be consistent with “happens before” (6.9.2.1). This allows more efficient implementation of memory_order::acquire and memory_order::release on some machine architectures. It can produce surprising results when these are mixed with memory_order::seq_cst accesses. — end note] 7 [Note: memory_order::seq_cst ensures sequential consistency only for a program that is free of data races and uses exclusively memory_order::seq_cst atomic operations. Any use of weaker ordering will invalidate this guarantee unless extreme care is used. In many cases, memory_order::seq_cst atomic operations are reorderable with respect to other atomic operations performed by the same thread. — end note] если чо, я не настоящий сварщик и, мб, херово распарсил :)
Обсуждают сегодня