Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932275Ab3CLOsH (ORCPT ); Tue, 12 Mar 2013 10:48:07 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:44194 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754027Ab3CLOsE (ORCPT ); Tue, 12 Mar 2013 10:48:04 -0400 Date: Tue, 12 Mar 2013 07:38:53 -0700 From: "Paul E. McKenney" To: Ming Lei Cc: Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org, Shaohua Li , Al Viro Subject: Re: [PATCH] atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive Message-ID: <20130312143853.GD3725@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1362843501-31159-1-git-send-email-tom.leiming@gmail.com> <20130312033906.GA3725@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13031214-7182-0000-0000-000005C0A5AC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2141 Lines: 56 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 > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/