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: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.
> 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.
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?
there are often a wide range of conditions we never think of when to
consider whether something will be a problem. It is for that reason I
prefer balanced binary trees to hashes :-)