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. Paolo
