I don't think you're giving much credit to people who were programming multi-processor systems at that time. As @mhh_ points out, the vast majority weren't writ

I don't think you're giving much credit to people who were programming multi-processor systems at that time. As @mhh_ points out, the vast majority weren't writing code that was multi-threaded at all. Of those who were, fewer still were writing the kind of code that was so tightly synchronized that these issues would even surface. OS engineers (such as myself) and others who did so were typically much closer to the hardware and aware that it was a rapidly evolving field, so they knew to watch out for these kinds of land mines. If you want to cite "surprising results" and "odd mysterious crashes" try making it more than conjecture by providing some data. I was there and such things didn't seem particularly more common on Alpha than elsewhere. Years later, as I said somewhere in this thread, I worked with another (MIPS-based) chip designed by some of the Alpha engineers, with the same predilection for weak memory ordering. In about two years, I found three bugs related to missing memory barriers - one in NFS, one in NBD, and one in Lustre (which isn't even part of the kernel). Yes, they were a pain to debug. Part of the reason is that they would occur so damn rarely. Damn near 100% of the time the "vulnerable" code would run just fine anyway. Writing reproducers was a serious challenge. More importantly, these bugs were dwarfed by bugs of many other more familiar types - use after free, deadlock, protocol errors, etc. Any bugginess attributable to the weak memory model was noise. So yeah, Alpha's performance was very real. Using hypotheticals to bash it in pseudo-retrospect seems uncharitable, to say the least.