On 05/05/17 18:59, Andrew Haley wrote: > On 05/05/17 17:31, Toebs Douglass wrote: >> 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. I may be wrong, but I think you might be thinking about store barriers being built into atomic operations; if so, I don't mean that in what I say. I mean that a bare atomic operation (LL/SC / LOCK), bereft of memory barriers, forces a store to memory, and that this in turn forces 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. > > Well, you can't do hazard pointers without CAS, so I don't think that > the issue arises. I may be *completely* wrong, I only implemented hazard pointers for the first time about four months ago, but I think they are implemented with memory barriers only. What is the CAS being used for? >> 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. Yes. I would like to know what you're doing with CAS in hazard pointers though, because my implementation may be wrong. That's something for email though, rather than the GCC help mailing list :-)
