On Monday 02 June 2014 09:45:46 Tim Blechmann wrote:
hi andrey,
I'm reviewing (again) Boost.Atomic code and struggling to understand the consume order and in particular what should it mean on architectures other than DEC Alpha.
I read the explanation here:
http://en.cppreference.com/w/cpp/atomic/memory_order
but the point eludes me. Take ARM for example and the explanation in the "Release-Consume ordering" section. The producer thread allocates the string and stores the pointer with a release operation, so that the pointer, the string contents and the 'data' integer are visible to other threads.
Now the consumer thread reads the pointer with a consume operation. According to the explanation in the article, on ARM the consume operation need not issue any specific fences to be able to use the pointer and the string body. In that case, the consume operation becomes equivalent to relaxed (plus prohibiting compiler optimizations). But is there a guarantee that the string body will be visible to the consumer? Shouldn't the consume operation be promoted to acquire instead?
the alpha can speculatively load an memory region. the consume semantics prevents issues a memory barrier to make sure that the memory is read after the atomic pointer is written to. so from my understanding, on arm and x86, relaxed has the same guarantee than consume ...
would be great if someone could confirm this, though.
There is some discussion in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm In particular it mentions that ARM and PPC reorder data-dependent operations, so I assume it means a fence is required? BTW, gcc 4.8 generates fences for consume loads, similarly to acquire, for both ARM and PPC. It may be that gcc devs just went the simplest and safest route when implementing consume though.