CPU's, Concurrency And Programs

Sean Mcgrath writes,concurrent programs are hard to write, hard to read and hard to debug. Although developers dislike the complexity of concurrency, they are very, very fond of getting the most out of their CPUs. Historically, writing your program down at the machine code level was all you needed to do to ensure that you had maximum access to your processing power. Excerpts with edits:
However, recent developments in processor architectures such as hyper-threading are set to break this simple relationship between access to processing power and machine code programming. Processor makers are starting to put multiple classical 'CPUs' on a single chunk of silicon. Consequently, in order to best use the available power, it is no longer sufficient to program at a machine code level. The key to true performance maximization is now concurrency - getting those logically separate CPUs doing useful things at the same time.
Unfortunately, as we have seen, concurrency is hard. Very hard. It will be interesting to see how the tools of the trade change at a software level as a result of this change at the hardware level. Concurrent programming with languages/tools that do not help you and protect you from underlying complexity of concurrency is a recipe for hypertension. Yet more layers of tool support on top of 'classical' single-CPU languages is one possibility. A quantum leap into the limelight for languages like Erlang [2] is another. whatever happens, it is going to become increasingly difficult for developers to avoid the complex and subtle issues that are associated with concurrency.