[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atom

From: Pranith Kumar
Subject: Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions
Date: Mon, 4 Apr 2016 23:35:40 -0400

On Mon, Apr 4, 2016 at 1:03 PM, Paolo Bonzini <address@hidden> wrote:

>> Quoting 
>> http://www.inf.pucrs.br/~flash/progeng2/cppreference/w/cpp/atomic/atomic_thread_fencehtml.html:
>> "Establishes memory synchronization ordering of non-atomic and relaxed
>> atomic accesses"
> You can find some information at
> https://bugzilla.redhat.com/show_bug.cgi?id=1142857 and

This bug seems to be out-of-bounds. I get a message saying that the
bug has been restricted for internal development processes.

> https://retrace.fedoraproject.org/faf/problems/670281/.
> I've looked at private email from that time and I was pointed to this
> sentence in GCC's manual, which says the opposite:
>     "Note that in the C++11 memory model, fences (e.g.,
>     ‘__atomic_thread_fence’) take effect in combination with other
>     atomic operations on specific memory locations (e.g., atomic loads);
>     operations on specific memory locations do not necessarily affect
>     other operations in the same way."
> Basically, the __atomic fences are essentially a way to break up a
> non-relaxed atomic access into a relaxed atomic access and the
> ordering-constraining fence.  According to those emails, atomic
> load-acquires and store-releases can provide synchronization for plain
> loads and stores (not just for relaxed atomic loads and stores).
> However, an atomic thread fence cannot do this.

Yes, on further research... this looks to be the case. I think I
understand the reasoning for this is to separate synchronization
variables/objects vs data.

> It depends on the compiler you're using.  With some luck, reverting the
> patch will cause accesses across smp_wmb() or smp_rmb() to get
> reordered.  In our case it was in thread-pool.c; Kevin Wolf did the
> analysis.

If ordering was crucial for those stores, I think it would have been
better to use atomics on them to enforce ordering.

Also, do you plan to introduce load_acquire/store_release() operations
like done in the linux kernel? They would cleanly map to gcc atomics
and make the ordering requirements explicit.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]