Re: [PATCH v2] util/async: Add memory barrier to aio_ctx_prepare

[Paolo Bonzini <pbonzini@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1111 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]