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