The simple fact is that most client-facing applications spend most of their time idle, waiting for user input. There's just no incentive to break their functions down into highly parallelizable units.
Furthermore, many commonplace tasks resist concurrency. Multimedia encoding is one of the more processor-intensive activities that a typical user might engage in, for example, but many popular MP3 encoders are linear, single-threaded processes that don't benefit from multiprocessing. The best way to improve performance is to launch two separate MP3 encoders at the same time and have each use a single processor core to work on a separate file.
That's why a solution like Apple's Grand Central is probably the best choice for a client-facing system like Mac OS X. Putting the OS in charge of concurrency allows single-threaded applications to coexist peacefully with more processor-intensive, highly parallel ones. But as long as developers need to learn exotic new concepts to master concurrency, I expect the number of single-threaded applications to vastly outnumber the concurrent ones.
Where will the highly concurrent, multithreaded applications be found? On the Web, of course -- where programmers are free to write purpose-built concurrent applications that don't need to worry about being interrupted by a screen saver. Nor do they need to coexist on the same hardware with other developers' Web-based apps.
Adding cores and trumpeting greater CPU power through concurrency is great marketing for hardware vendors like Intel -- and Apple -- but the truth is that today's high-end PCs have long since exceeded the performance needs of casual users. It's little wonder that netbooks are the hot hardware trend. Forget multiple cores; customer demand is even driving clock speeds downward. Complex processing is moving outward, into the cloud.
That's why, when I hear that every developer will soon need to retrain to code for concurrency, I can't help but be skeptical. From an academic standpoint, tools such as Axum, Fortress, and Grand Central are fascinating. But from the standpoint of the everyday developer, all this hubbub about concurrency may ultimately prove to be nothing more than a tempest in a teapot.