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).
This was a very interesting post, but to be honest it didn't make me think "I need to learn more about multithreading", it just convinced me that I need to continue to stay away from multithreading whenever at all possible [1]. Having programs run in a way that's so far away from the way you would expect <i>can't</i> be the right way to do things.<p>[1] I tend to use processes and IPC whenever I can, for example.
The real takeaway is:<p>- Don't write this stuff on your own.<p>- Use someone else's mutex, and someone else's non-blocking datastructure.<p>- Really, don't write your own.<p>Threading is not that hard unless you insist on leaving the safety off and aiming it at your foot.