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.
