Paul E. McKenney wrote:

On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:

quoted

                                If you're depending on volatile writes 
being visible to other CPUs, you're screwed either way, because the CPU can 
hold that data in cache as long as it wants before it writes it to memory.  
When this finally does happen, it will happen atomically, which is all that 
atomic_set guarantees.  If you need to guarantee that the value is written 
to memory at a particular time in your execution sequence, you either have 
to read it from memory to force the compiler to store it first (and a 
volatile cast in atomic_read will suffice for this) or you have to use 
LOCK_PREFIX instructions which will invalidate remote cache lines 
containing the same variable.  This patch doesn't change either of these 
cases.

The case that it -can- change is interactions with interrupt handlers.
And NMI/SMI handlers, for that matter.

You have a point here, but only if you can guarantee that the interrupt handler 
is running on a processor sharing the cache that has the not-yet-written 
volatile value.  That implies a strictly non-SMP architecture.  At the moment, 
none of those have volatile in their declaration of atomic_t, so this patch 
can't break any of them.

	-- Chris