There are major pushes by all the big players towards easing this type of development. IBM is making tons of tools for debugging, design, etc. Sun, IBM, Cray, Microsoft are all researching new or developing new APIs/languages to ease the burden. New methodologies for accessing memory, ie transactionally. All in the hope to reduce deadlocks, data races, and any other concurrency issue. But for now developers should not think about how to make an application multi-threaded, but instead think about how to make a program scalable. Create it with the idea of independent jobs and tasks that should work with 1 thread, but also be able to make use of any number of additional cores being thrown at it. Almost like developing J2EE server side applications like servlets and EJBs, where you can just add more instances if the load gets too much and the applications are developed right.

I'm gonna make a venture here and say that as time goes on multi-core will become like normal programming. Back in the day you had to deal with all the cards, then you got the modern computer and assembly, so and so forth, now you have your Java, Ruby, w/e. You can write you entire games purely on assembly which would run on computers from a decade ago, yet I'm sure you'd commit suicide within a few months. My bet is that the same will happen with multi-core programming. It will become far more accessible and bareable, but it just won't be as efficient.