Re: [boost] [atomic] Help understanding consume order

Subject: Re: [boost] [atomic] Help understanding consume order
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-02 04:26:40

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.