This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Memory model release/acquire mode interactions of relaxed atomic operations
On 05/05/17 17:31, Toebs Douglass wrote:
> On 05/05/17 17:17, Andrew Haley wrote:
>> On 05/05/17 12:37, Toebs Douglass wrote:
>
>>> https://cr.yp.to/2005-590/sparcv9.pdf
>>>
>>> Section 8.4.3.1 Ordering MEMBAR Instructions (page 150)
>>>
>>> This section covers the LoadLoad, StoreLoad, LoadStore and StoreStore
>>> barriers.
>>>
>>> "An ordering MEMBAR instruction does not guarantee any completion
>>> property; it only introduces an ordering constraint."
>>
>> Sure, but in portable code ordering constraints are all we have.
>
> You get atomic operations as well. Where they force a store, they also
> force the honouring of earlier store barriers.
That's wrong on some platforms, such as ARM. So you are making an
unsafe assumption.
>> There is nothing stronger. And a correct program never needs anything
>> more than ordering constraints unless you're doing something very odd
>> with caches or I/O devices.
>
> I suspect - although I have not proved it - that hazard pointers can
> break because of this. That would certainly make it a real issue.
Well, you can't do hazard pointers without CAS, so I don't think that
the issue arises.
> Regardless, in general I don't feel comfortable relying on race
> conditions not to happen - what happens if the code is running on some
> machine with massive numbers of cores with very high inter-core latency?
Ordering is all that matters for correctness in *any* of these
algorithms. As long as you get the ordering right, latency can never
do anything other than slow things down.
But I think I've got to the end of this road.
Andrew.