Messages in this thread | | | Date | Tue, 12 Mar 2013 07:38:53 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive |
| |
On Tue, Mar 12, 2013 at 12:03:23PM +0800, Ming Lei wrote: > On Tue, Mar 12, 2013 at 11:39 AM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> 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.
Frederic was likely thinking of some other scenario that would be broken by atomic_inc_unless_negative() failing to act as a full memory barrier. Here is another example:
CPU 0 CPU 1
X = 1; if (atomic_inc_unless_negative(&Y) r1 = atomic_xchg(&Y, -1); r2 = X;
If atomic_inc_unless_negative() acts as a full memory barrier, then if CPU 0 reaches the assignment from X, the results will be guaranteed to be 1. Otherwise, there is no guarantee.
Thanx, Paul
| |