First up, Ridiculous Fish's article on shared-memory multithreading makes a good case for why testing often isn't likely to find mt bugs.

This is one of those 'how deep does the rabbit-hole go?' kind of posts, and is well worth a read. The characterisation of modern CPUs being vastly optimised for single-threaded code is one I hadn't really considered, and I certainly hadn't realized how much more stringent memory read ordering on X86 was compared to other CPU architectures. This means that MT code running fine on multiproc intel boxes may not behave well on other architectures.

Then a followup re-adjusting newbies to the complexities of using memory barriers for synchronisation.

Finally a small one quantifying the speed impact of cache line bounces.

To me these all add reason to think carefully before employing shared-state multithreading as a central theme in your next architecture.

I'm on a sleepy late train home from London to Birmingham (trying to avoid the snow and inevitable rail problems tomorrow). This woke me up:

Patrick Logan says STM "...would be the most tragic turn imaginable for programming in the 21st century."

Very wrong. And it is scaring me how shiny this thingy looks in so many people's eyes right now. I don't think it will be so long before this shows up in Java and C#.

Blimey, that's gonna cause a bit of a ruckus.

(Update: Yep - the comments have started)