Please read the Linux documentation on memory barriers instead of this:
<a href="http://lxr.linux.no/linux+v2.6.35/Documentation/memory-barriers.txt" rel="nofollow">http://lxr.linux.no/linux+v2.6.35/Documentation/memory-barri...</a><p>The Ridiculous Fish guy is clearly very smart and writes lots of interesting stuff, but this is obviously not his area of expertise, and you can't afford to learn from someone who has any confusion on the topic.<p>In his conclusion he makes what I would consider a highly misleading comparison between locks and memory barriers. He calls locks "tanks" ("powerful, slow, safe, expensive, and prone to getting you stuck"). About memory barriers he says: "Memory barriers are a faster, non-blocking, deadlock free alternative to locks. They take more thought, and aren’t always applicable, but your code’ll be faster and scale better."<p>But memory barriers aren't an alternative to locks at all. Locks let multiple threads <i>write</i> to shared memory. Memory barriers by themselves aren't very useful; most lock-free algorithms need atomic operations like compare-and-swap, which are comparable in cost to locks (indeed, locks are implemented in terms of atomic operations).