Concurrency

Concurrency is terribly difficult. Example: a primary cause of the massive North American blackout in 2003 was a software race condition. The application logged over three million production hours before the bug manifested itself.

Nevertheless, concurrency, here we come. Herb Sutter points out why with his article: “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”.

Mr. Sutter explains how future CPU improvements will no longer give applications a free performance boost - clock speed and execution optimizations are topping out. We need to increase the concurrency of our applications to take advantage of the next wave of CPU improvements (multiple cores).

Like Jeff Atwood, I don’t think concurrency is an area the typical application developer is ever going to deal with. Instead, the revolution will happen in the runtimes, the platforms, and the languages we use.

ASP.NET developers already use a runtime to write applications that process requests in parallel. Even a simple console mode program in the CLR has work happening concurrently. On the platform side, T-SQL developers have parallelism readily available with SQL Server’s Service Broker on the horizon.

While the platforms and runtimes are moving ahead, I’m not sure what is happening with languages. When Comega first appeared I thought the next version of C# would be taking a turn towards new concurrency abstractions, but I see no mention of these in the C# 3.0 specification.

As far as languages go, perhaps the LINQ / DLinq / XLinq features are enough to chew on and iron out first.