On Thu, Apr 02, 2020 at 11:59:06AM +0200, Paolo Bonzini wrote: > 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
Thanks. I know you are probably very busy right now, but updating atomics.txt would be great. Stefan
signature.asc
Description: PGP signature
