On 11/06/15 22:38, Sebastian wrote: > On Thu, 11 Jun 2015 12:21:23 +0100 > Andrew Haley <aph@xxxxxxxxxx> wrote: > >> I'd use a full memory barrier. __sync_synchronize() > Isn't __sync_synchronize() the same as a memory clobber + hardware barrier? It's a compiler barrier and a hardware barrier. If you processor has no hardware barriers, then it's just a compiler barrier. It does the right thing either way. >> this guarantees that no memory operations will not >> be moved across the barrier. > Still the open question: Is access to array elements (or > dereferencing a pointer) always considered a "memory operation", Yes. > unlike the variable access in the example in [2]? Eh? The vriable access is a memory operation in [2]. It is surrounded by the cli/sei, as required. We cannot guarantee that non-memory operations will not be reordered with memory barriers, though. >> or one of the __atomic fences. > As far as I can see, you can only use them on integers or pointers, > but not on arrays. This makes no sense. A fence is a fence. It is not attached to any memory location. No memory access can move across it. > So you think it would be enough to do the pointer manipulations > atomically, and then the array accesses which depend on these > pointers should be ok? That's what I'm thinking, too, but what I'm > not sure about... This makes no sense either. Andrew.
