Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936402AbXHOUyN (ORCPT ); Wed, 15 Aug 2007 16:54:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757898AbXHOUxw (ORCPT ); Wed, 15 Aug 2007 16:53:52 -0400 Received: from gate.crashing.org ([63.228.1.57]:49982 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756921AbXHOUxv (ORCPT ); Wed, 15 Aug 2007 16:53:51 -0400 In-Reply-To: References: <20070809131423.GA9927@shell.boston.redhat.com> <46C2D6F3.3070707@s5r6.in-berlin.de> <9350e9fab505c92af8d5e1f3441d6ad2@kernel.crashing.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit 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 From: Segher Boessenkool Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures Date: Wed, 15 Aug 2007 22:42:08 +0200 To: Satyam Sharma X-Mailer: Apple Mail (2.623) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1564 Lines: 64 >> 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. Yes, accesses to volatile objects are never reordered with respect to each other. > 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. Of course. It is executed by the abstract machine, so it will be executed by the actual machine. On the other hand, try b = 0; if (b) b = atomic_read(a); or similar. Segher - 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/