Satyam Sharma wrote:
quoted text
> On Tue, 24 Jul 2007, Nick Piggin wrote:
> 

quoted text
>>For the purpose of this discussion (Linux memory
>>barrier semantics, on WB memory), it is true of CPU
>>and compiler barriers.
> 
> 
> On later Intel processors, if the memory address range being referenced
> (and say written to) by the (locked) instruction is in the cache of a
> CPU, then it will not assert the LOCK signal on the system bus --
> thus not assume exclusive use of shared memory. So other CPUs are free
> to modify (other) memory at that point. Cache coherency will still
> ensure _that_ (locked) memory area is still updated atomically, though.

The system bus does not need to be serialised because the CPU already
holds the cacheline in exclusive state. That *is* the cache coherency
protocol.

The memory ordering is enforced by the CPU effectively preventing
speculative loads to pass the locked instruction and ensuring all
stores reach the cache before it is executed. (I say effectively
because the CPU might do clever tricks without you knowing).


quoted text
>>Are you saying that it is OK for the store to var to
>>be reordered below the clear_bit? If not, what are you
>>saying?
> 
> 
> I might be making a radical turn-around here, but all of a
> sudden I think it's actually a good idea to put a complete
> memory clobber in set_bit/clear_bit and friends themselves,
> and leave the "__" variants as they are.

Why?

-- 
SUSE Labs, Novell Inc.
-
unsubscribe notice
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/