On Tue, Mar 12, 2013 at 11:39 AM, Paul E. McKenney <[email protected]> wrote: > > Atomic operations that return a value are required to act as full memory > barriers. This means that code relying on ordering provided by these > atomic operations must also do ordering, either by using an explicit > memory barrier or by relying on guarantees from atomic operations. > > For example: > > CPU 0 CPU 1 > > X = 1; r1 = Z; > if (atomic_inc_unless_negative(&Y) smp_mb(); > do_something(); > Z = 1; r2 = X; > > Assuming X and Z are initially zero, if r1==1, we are guaranteed > that r2==1. However, CPU 1 needs its smp_mb() in order to pair with > the barrier implicit in atomic_inc_unless_negative(). > > Make sense?
Yes, it does, and thanks for the explanation. But looks the above example is not what Frederic described: "the above atomic_read() might return -1 because there is no guarantee it's seeing the recent update on the remote CPU." Even I am not sure if adding one smp_mb() around atomic_read() can guarantee that too. Andrew, please ignore the patch, thanks. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
