On Mon, Apr 4, 2016 at 1:03 PM, Paolo Bonzini <pbonz...@redhat.com> 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. Thanks! -- Pranith
