Date: Wed, 8 Aug 2007 10:27:05 +0800
From: Jerry Jiang <wjiang@resilience.com>
To: Chris Snook <csnook@redhat.com>
Cc: Chris Friesen <cfriesen@nortel.com>,
       "Robert P. J. Day" <rpjday@mindspring.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: why are some atomic_t's not volatile, while most are?
Message-Id: <20070808102705.9d91a14c.wjiang@resilience.com>
In-Reply-To: <46B8D6D7.2020206@redhat.com>
References: <Pine.LNX.4.64.0707010847370.22564@localhost.localdomain>
	<20070806123551.a6c3c154.wjiang@resilience.com>
	<46B72C58.5030502@redhat.com>
	<46B894E4.4010501@nortel.com>
	<46B8D6D7.2020206@redhat.com>
Organization: Resilience
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1078
Lines: 28

On Tue, 07 Aug 2007 16:32:23 -0400
Chris Snook <csnook@redhat.com> wrote:

> > It seems like this would fall more into the case of the arch providing 
> > guarantees when using locked/atomic access rather than anything 
> > SMP-related, no?.
> 
> But if you're not using SMP, the only way you get a race condition is if your 
> compiler is reordering instructions that have side effects which are invisible 
> to the compiler.  This can happen with MMIO registers, but it's not an issue 
> with an atomic_t we're declaring in real memory.
> 

Under non-SMP, some compilers would reordering instructions as they think
and C standard informally guarantees all operations on volatile data
are executed in the sequence in which they appear in the source code,
right?

So no reordering happens with volatile, right?

-- Jerry

> 	-- Chris
-
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/