* Paolo Bonzini (pbonz...@redhat.com) wrote: > > > On 23/03/2015 03:20, David Gibson wrote: > >>> 1) There's no barrier after the write, so there's no guarantee > >>> the other thread will eventually see it (in practice we've got > >>> other pthread ops we take so we will get a barrier somewhere, > >>> and most CPUs eventually do propagate the store). > > Sorry, I should have been clearer. If you need a memory barrier, > > by all means include a memory barrier. But that should be > > explicit: atomic set/read operations often include barriers, but > > it's not obvious which side will include what barrier. > > Memory barriers are not needed here. The variable is set > independently from every other set. There's no ordering. > > atomic_read/atomic_set do not provide sequential consistency. That's > ensured instead by atomic_mb_read/atomic_mb_set (and you're right that > it's not obvious which side will include barriers, so you have to use > the two together). > > >>> 2) The read side could legally be optimised out of the loop by > >>> the compiler. (but in practice wont be because compilers won't > >>> optimise that far). > > That one's a trickier question. Compilers are absolutely capable > > of optimizing that far, *but* the C rules about when it's allowed > > to assume in-memory values remain unchanged are pretty > > conservative. I think any function call in the loop will require > > it to reload the value, for example. That said, a (compiler only) > > memory barrier might be appropriate to ensure that reload. > > That's exactly what atomic_read provides.
So does that say I need the atomic_read but not the atomic_write - which seems a bit weird, but I think only due to the naming. Dave > > Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
