Hacker News Reader

Comment by mjb | Hacker News Reader

This is a really interesting article. Multi-core ARM seems to be the first really mainstream processor architecture that behaves this way. There have been others, like Alpha, but none have achieved the ubiquity that mult-core ARM has achieved. I suspect a side-effect of this is that many of the "threads are hard" effects that are hidden by x86 will come back to bite a lot of programmers. I think we are going to be seeing a lot more "threads are hard" and "threads and weird" posts in the near future, and hopefully better learning material about threading issues in the longer term. Even more hopefully, this might drive more research and development into abstractions for providing parallelism and concurrency in ways that hide the complexity of threads.

View on HN

PowerPC has a weakly ordered memory model, so older Mac programmers are no strangers to this sort of stuff.

There have been many multi-core ARM devices out in both the Android and iOS world for a few years, and I haven't heard too many complaints. I think most good high-level programmers know that they need to use high-level locks provided by the SDK, while anyone writing code that actually needs to deal with memory ordering probably already knows to use barriers some of the pitfalls of different ISAs.

But old PowerPC macs weren't typically multicores, and even when they had multiple CPUs, people rarely programmed threaded software for them. Memory ordering is completely transparent to a single thread -- it's only when you add more of them that you start to have problems.

http://en.wikipedia.org/wiki/List_of_Macintosh_models_groupe...

All of the PowerMac G4s and PowerMac G5s from 1999-2006 spanning 350MHz to 2.7GHz were sold in multiprocessor configurations.

Maybe most programmers never worried about writing threaded software for them, but they certainly weren't uncommon.

Only the most expensive PowerMacs had multiprocessors; iMacs, PowerBooks, and iBooks vastly outnumbered those with top-end PowerMacs. Which also meant there wan't much point in writing heavily threaded programs unless specifically targeting high-end users.

> PowerPC has a weakly ordered memory mode

Right, I forgot about PowerPC.

> I think most good high-level programmers know that they need to use high-level locks provided by the SDK, while anyone writing code that actually needs to deal with memory ordering probably already knows to use barriers some of the pitfalls of different ISAs.

Agreed. The point I was trying to make is that, as these platforms become ubiquitous, they'll start attracting the "average" developer more and the "first mover" developers less. I can't prove that "more likely to move onto a new platform" is correlated with "more likely to be aware of threading pitfalls", but I suspect it to be true.

> so older Mac programmers are no strangers to this sort of stuff.

And embedded software programmers. There is still a market for chips that don't consume more power than an electric blanket.

Same for game developers -- the Xbox 360 and PS3 were both multi-core PowerPC architectures (of sorts) that required the developers pay close attention to their barriers when writing concurrent code.

You don't hear complaints because no one is going to find a bug caused by weak memory ordering without already knowing about memory reordering. In real buggy code, failures are so rare that most developers will never personally see a failure. Even the article's contrived case that should fail a hundred times more often than real code does, only fails one time out of a thousand. And if the bug only causes a slight graphical glitch, well, the developer will never notice it on their own. Or explain it as a hundred other things.

I've seen several people who thought they were smart, write code that needed memory barriers and never realize it. Or think that volatile made things safe. Getting them to accept that their code was buggy was hard.

Reply on news.ycombinator.com