On Saturday 08 July 2006 15:40, Chase Venters wrote:
> You need the barrier for both the CPU and the compiler. The CPU barrier
> comes from an instruction like '*fence' on x86 (or a locked bus op), while
> the compiler barrier comes from the memory clobber. Because the spinlocks
> already _must_ have both of these (including the other constraints in the
> inline asm), 'volatile' on the spinlock ctr is useless.
Btw, perhaps what is going on here is a misunderstanding of
terminology? "Barrier" or "Memory barrier" can refer to both a hardware or
compiler barrier, which is why Documentation/memory-barriers.txt speaks of
both in the same file. Indeed, you often have both in the same spot, and the
names are even similar:
barrier() -> compiler memory barrier
wmb() -> write memory barrier
...
Sometimes you'll see "optimization barrier", but you should remember that
barrier() boils down to:
asm volatile ("" ::: "memory")
...because it's preventing memory caching/reordering across the unpredictable
memory clobber.
See?
>
> Thanks,
> Chase
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
