This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]