Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761654AbXHONI4 (ORCPT ); Wed, 15 Aug 2007 09:08:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755588AbXHONIr (ORCPT ); Wed, 15 Aug 2007 09:08:47 -0400 Received: from hp3.statik.tu-cottbus.de ([141.43.120.68]:38172 "EHLO hp3.statik.tu-cottbus.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755521AbXHONIp (ORCPT ); Wed, 15 Aug 2007 09:08:45 -0400 Message-ID: <46C2FADB.7020407@s5r6.in-berlin.de> Date: Wed, 15 Aug 2007 15:08:43 +0200 From: Stefan Richter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Satyam Sharma CC: 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, Herbert Xu , "Paul E. McKenney" Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures References: <20070809131423.GA9927@shell.boston.redhat.com> <46C2D6F3.3070707@s5r6.in-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2464 Lines: 83 Satyam Sharma wrote: > On Wed, 15 Aug 2007, Stefan Richter wrote: >> Doesn't "atomic WRT all processors" require volatility? > > No, it definitely doesn't. Why should it? > > "Atomic w.r.t. all processors" is just your normal, simple "atomicity" > for SMP systems (ensure that that object is modified / set / replaced > in main memory atomically) and has nothing to do with "volatile" > behaviour. > > "Volatile behaviour" itself isn't consistently defined (at least > definitely not consistently implemented in various gcc versions across > platforms), but it is /expected/ to mean something like: "ensure that > every such access actually goes all the way to memory, and is not > re-ordered w.r.t. to other accesses, as far as the compiler can take > care of these". The last "as far as compiler can take care" disclaimer > comes about due to CPUs doing their own re-ordering nowadays. > > For example (say on i386): [...] > In (A) the compiler optimized "a = 10;" away, but the actual store > of the final value "20" to "a" was still "atomic". (B) and (C) also > exhibit "volatile" behaviour apart from the "atomicity". > > But as others replied, it seems some callers out there depend upon > atomic ops exhibiting "volatile" behaviour as well, so that answers > my initial question, actually. I haven't looked at the code Paul > pointed me at, but I wonder if that "forget(x)" macro would help > those cases. I'd wish to avoid the "volatile" primitive, personally. So, looking at load instead of store, understand I correctly that in your opinion int b; b = atomic_read(&a); if (b) do_something_time_consuming(); b = atomic_read(&a); if (b) do_something_more(); should be changed to explicitly forget(&a) after do_something_time_consuming? If so, how about the following: static inline void A(atomic_t *a) { int b = atomic_read(a); if (b) do_something_time_consuming(); } static inline void B(atomic_t *a) { int b = atomic_read(a); if (b) do_something_more(); } static void C(atomic_t *a) { A(a); B(b); } Would this need forget(a) after A(a)? (Is the latter actually answered in C99 or is it compiler-dependent?) -- Stefan Richter -=====-=-=== =--- -==== http://arcgraph.de/sr/ - 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/