Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935827AbXHOT2P (ORCPT ); Wed, 15 Aug 2007 15:28:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760882AbXHOT1x (ORCPT ); Wed, 15 Aug 2007 15:27:53 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:59816 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754456AbXHOT1w (ORCPT ); Wed, 15 Aug 2007 15:27:52 -0400 Date: Thu, 16 Aug 2007 01:10:15 +0530 (IST) From: Satyam Sharma X-X-Sender: satyam@enigma.security.iitk.ac.in To: Segher Boessenkool cc: Christoph Lameter , heiko.carstens@de.ibm.com, horms@verge.net.au, Stefan Richter , Linux Kernel Mailing List , "Paul E. McKenney" , netdev@vger.kernel.org, ak@suse.de, cfriesen@nortel.com, rpjday@mindspring.com, jesper.juhl@gmail.com, linux-arch@vger.kernel.org, Andrew Morton , zlynx@acm.org, schwidefsky@de.ibm.com, Chris Snook , Herbert Xu , davem@davemloft.net, Linus Torvalds , wensong@linux-vs.org, wjiang@resilience.com Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures In-Reply-To: <9350e9fab505c92af8d5e1f3441d6ad2@kernel.crashing.org> Message-ID: References: <20070809131423.GA9927@shell.boston.redhat.com> <46C2D6F3.3070707@s5r6.in-berlin.de> <9350e9fab505c92af8d5e1f3441d6ad2@kernel.crashing.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2615 Lines: 84 On Wed, 15 Aug 2007, Segher Boessenkool wrote: > > "Volatile behaviour" itself isn't consistently defined (at least > > definitely not consistently implemented in various gcc versions across > > platforms), > > It should be consistent across platforms; if not, file a bug please. > > > 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 ^ (volatile) (or, alternatively, "other accesses to the same volatile object" ...) > > care of these". The last "as far as compiler can take care" disclaimer > > comes about due to CPUs doing their own re-ordering nowadays. > > You can *expect* whatever you want, but this isn't in line with > reality at all. > > volatile _does not_ prevent reordering wrt other accesses. > [...] > What volatile does are a) never optimise away a read (or write) > to the object, since the data can change in ways the compiler > cannot see; and b) never move stores to the object across a > sequence point. This does not mean other accesses cannot be > reordered wrt the volatile access. > > If the abstract machine would do an access to a volatile- > qualified object, the generated machine code will do that > access too. But, for example, it can still be optimised > away by the compiler, if it can prove it is allowed to. As (now) indicated above, I had meant multiple volatile accesses to the same object, obviously. BTW: #define atomic_read(a) (*(volatile int *)&(a)) #define atomic_set(a,i) (*(volatile int *)&(a) = (i)) int a; void func(void) { int b; b = atomic_read(a); atomic_set(a, 20); b = atomic_read(a); } gives: func: pushl %ebp movl a, %eax movl %esp, %ebp movl $20, a movl a, %eax popl %ebp ret so the first atomic_read() wasn't optimized away. > volatile _does not_ make accesses go all the way to memory. > [...] > If you want stuff to go all the way to memory, you need some > architecture-specific flush sequence; to make a store globally > visible before another store, you need mb(); before some following > read, you need mb(); to prevent reordering you need a barrier. Sure, which explains the "as far as the compiler can take care" bit. Poor phrase / choice of words, probably. - 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/