Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754931AbXHQEC0 (ORCPT ); Fri, 17 Aug 2007 00:02:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751081AbXHQECO (ORCPT ); Fri, 17 Aug 2007 00:02:14 -0400 Received: from ozlabs.org ([203.10.76.45]:56028 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750918AbXHQECM (ORCPT ); Fri, 17 Aug 2007 00:02:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18117.7611.660070.879392@cargo.ozlabs.ibm.com> Date: Fri, 17 Aug 2007 14:02:03 +1000 From: Paul Mackerras To: Nick Piggin Cc: paulmck@linux.vnet.ibm.com, Herbert Xu , Stefan Richter , Satyam Sharma , Christoph Lameter , Chris Snook , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Linus Torvalds , netdev@vger.kernel.org, Andrew Morton , ak@suse.de, heiko.carstens@de.ibm.com, davem@davemloft.net, schwidefsky@de.ibm.com, wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com, cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com, jesper.juhl@gmail.com, segher@kernel.crashing.org Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures In-Reply-To: <46C512EB.7020603@yahoo.com.au> References: <18115.52863.638655.658466@cargo.ozlabs.ibm.com> <20070816053945.GB32442@gondor.apana.org.au> <18115.62741.807704.969977@cargo.ozlabs.ibm.com> <20070816070907.GA964@gondor.apana.org.au> <46C40587.7050708@s5r6.in-berlin.de> <20070816081049.GA1431@gondor.apana.org.au> <46C41EE4.9090806@s5r6.in-berlin.de> <46C42767.4070104@s5r6.in-berlin.de> <20070816104250.GB2927@gondor.apana.org.au> <20070816163441.GB16957@linux.vnet.ibm.com> <46C512EB.7020603@yahoo.com.au> X-Mailer: VM 7.19 under Emacs 21.4.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2337 Lines: 63 Nick Piggin writes: > Why are people making these undocumented and just plain false > assumptions about atomic_t? Well, it has only been false since December 2006. Prior to that atomics *were* volatile on all platforms. > If they're using lockless code (ie. > which they must be if using atomics), then they actually need to be > thinking much harder about memory ordering issues. Indeed. I believe that most uses of atomic_read other than in polling loops or debug printk statements are actually racy. In some cases the race doesn't seem to matter, but I'm sure there are cases where it does. > If that is too > much for them, then they can just use locks. Why use locks when you can just sprinkle magic fix-the-races dust (aka atomic_t) over your code? :) :) > > Precisely. And volatility is a key property of "atomic". Let's please > > not throw it away. > > It isn't, though (at least not since i386 and x86-64 don't have it). Conceptually it is, because atomic_t is specifically for variables which are liable to be modified by other CPUs, and volatile _means_ "liable to be changed by mechanisms outside the knowledge of the compiler". > _Adding_ it is trivial, and can be done any time. Throwing it away > (ie. making the API weaker) is _hard_. So let's not add it without Well, in one sense it's not that hard - Linus did it just 8 months ago in commit f9e9dcb3. :) > really good reasons. It most definitely results in worse code > generation in practice. 0.0008% increase in kernel text size on powerpc according to my measurement. :) > I don't know why people would assume volatile of atomics. AFAIK, most By making something an atomic_t you're saying "other CPUs are going to be modifying this, so treat it specially". It's reasonable to assume that special treatment extends to reading and setting it. > of the documentation is pretty clear that all the atomic stuff can be > reordered etc. except for those that modify and return a value. Volatility isn't primarily about reordering (though as Linus says it does restrict reordering to some extent). 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/