On 02/04/20 11:32, Stefan Hajnoczi wrote: > Paolo, I'm not sure how to interpret this case according to > docs/devel/atomics.txt. Maybe you can clarify. > > atomic_or() is sequentially consistent and I therefore expected it to > act as a barrier. Or does sequential consistency only cover the memory > accessed via the sequentially consistent atomics APIs and everything > else (like aio_compute_timeout()) can be reordered?
Yes, that's what I expected too when I wrote that code. :( But Torvald
Riegel explained a while ago that seq-cst accesses are actually weaker
than e.g. the Linux kernel atomics[1].
The difference basically only matters if you are writing the relatively
common synchronization pattern
write A write B
smp_mb() smp_mb()
read B read A
if not B then sleep if A then wake up the other side
do something
because you must either use memory barriers as above, or use seq-cst
writes *and* reads. You cannot rely on having a memory barrier implicit
in the writes.
Paolo
[1] https://lists.gnu.org/archive/html/qemu-arm/2019-10/msg00051.html
signature.asc
Description: OpenPGP digital signature
