What are the Challenges?

If we believe that dual/quad/octa/n-tuple cores + cache scaling + internals advancements is going to be the default way that processors are expected to scale, we must adjust the software appropriately to scale with it. Just as DOOM ran faster when I xcopied it from my old 486 to my Pentium 166 MMX, we need the same experience for our LOB apps, enterprise apps and so on.

When you start to think about how to solve the problem, an interesting meta-question arises: should we really be focusing on making sure client-side platforms scale? With the popular movement of apps to the web, perhaps you could equivocate the experience of upgrading from a 486 to a Pentium to that of going from 24 mbit ADSL 2+ to 100 mbit VHDSL? Users see their web apps load quicker with reduced latency - all without changes to the client side machine.

Let's delay tacking that meta-question for now (in fact, I'll be talking about it in Part 5: OS Hardware Virtualization & Cloud Computing), and just assume that at least for the next 5 years, we can expect that the market will keep adopting laptops, desktops and hardware coupled with a fat client operating system. To tackle the software / hardware scaling impedance mismatch, we'll need to adjust the software side.

Do away with Shared Memory, Threads and Locks

There's nothing stopping us from writing software that scales to ever-expanding cores - we've had basic concurrency building blocks since before I was born. Threads, Shared Memory and Locks are the typical tools used today, but I'd argue its through a lack of choice, rather than being the best tool for the job. Clearly they suck (in fact, without them I'd be out of a job as fixing race conditions is actually a really sweet rent-paying niche). Your average ISV programmer is going to struggle with it. What's worse, the bugs are almost impossible to diagnose with today's toolset - I've seen a torn read/write in the wild (e.g. a read of a 64 bit value from memory on a 32 bit wide machine requires two MOV instructions: thread 1 pauses after slurping in 32 of the higher order bits; thread 2 kicks in and performs a torn write over the lower order bits and pauses; thread 1 starts again, reading in the lower order bits overwritten by thread 2; bamo - broken invariant and a weird number to boot), and that was after days of sitting behind WinDbg.

• The World's Eight Most Excellent Software Adventures, Part One
• The World's Eight Most Excellent Software Adventures - Part Two