On Thu, Jun 08, 2017 at 02:16:41PM +0200, Peter Zijlstra wrote: > On Thu, Jun 08, 2017 at 12:24:33PM +0100, Will Deacon wrote:
> > The horribly out-of-date atomic_ops.txt isn't so useful: > > > > | If a caller requires memory barrier semantics around an atomic_t > > | operation which does not return a value, a set of interfaces are > > | defined which accomplish this:: > > | > > | void smp_mb__before_atomic(void); > > | void smp_mb__after_atomic(void); > > | > > | For example, smp_mb__before_atomic() can be used like so:: > > | > > | obj->dead = 1; > > | smp_mb__before_atomic(); > > | atomic_dec(&obj->ref_count); > > | > > | It makes sure that all memory operations preceding the atomic_dec() > > | call are strongly ordered with respect to the atomic counter > > | operation. In the above example, it guarantees that the assignment of > > | "1" to obj->dead will be globally visible to other cpus before the > > | atomic counter decrement. > > | > > | Without the explicit smp_mb__before_atomic() call, the > > | implementation could legally allow the atomic counter update visible > > | to other cpus before the "obj->dead = 1;" assignment. > > > > which makes it sound more like the barrier is ordering all prior accesses > > against the atomic operation itself (without going near cumulativity...), > > and not with respect to anything later in program order. > > This is correct. Ah, my bad, It orders against everything later, the first of which is (obviously) the atomic op itself. It being a full barrier means both the Read and the Write of the RmW must happen _after_ everything preceding. > > Anyway, I think that's sufficient for what we want here, but we should > > probably iron out the semantics of this thing. > > s/smp_mb__\(before\|after\)_atomic/smp_mb/g > > should not change the semantics of the code in _any_ way, just make it > slower on architectures that already have SC atomic primitives (like > x86). >
