Why Concurrency Is Becoming Dramatically More Important

From CommerceNet Wiki

Concurrency is very important, but most existing concurrent programming systems conflict with modularity and therefore increase complexity. If someone finds a way to make concurrency modular, and therefore manageable, and no fundamentally different strategy for making concurrency manageable is discovered, then nearly all code will be written this way by 2010. Since computer scientists have been searching for such a qualitative improvement for around 40 years, any claim for such a solution requires extensive verification. By the same token, it is unlikely that two different such breakthroughs will be discovered soon.

Better techniques for managing concurrency will be far more important in the near future than they have been in the past. For the past several years, CPUs have gotten faster only by getting bigger caches, more execution units, and lower prices, not by performing fundamental operations faster. Simple extrapolation suggests that in 2007, desktop CPUs with eight execution units will be available, so highly-concurrent programs may be able to run an order of magnitude faster than sequential programs; in 2010, the difference may be two to four orders of magnitude, as desktop CPUs may have 100 to 10 000 concurrent execution units.

It is likely that performance will continue to be important for everyday applications in the future; while the previous 50 years of repeated clock-rate doubling have made some applications less performance-sensitive, the more salient effect has been to bring a wider and wider class of applications into the mainstream, as limits on computational power have become less and less restrictive; and also to allow the use of implementation and deployment techniques that demand more and more CPU power. We can probably expect this 50-year trend to continue for another 10 years, at least.

However, such a breakthrough in expressiveness would also have other implications. Concurrency is also important, for example, when enforcing security or reliability boundaries between pieces of code; it is often important to keep one from starving the other of execution time, which minimally requires running it in a different thread, and expressing the interactions between the threads in a nonblocking or limited-blocking fashion. Thus concurrency, and in particular lock-free concurrency, is crucial for extending the usefulness of mobile-code systems. Also, many computations seem to be described most naturally in terms of multiple threads, but the modularity-breaking aspects of popular concurrency constructs mean that less natural descriptions are more usable.

One candidate for such a breakthrough is Composable Memory Transactions, by Tim Harris, Simon Marlow, Simon Peyton Jones, and Maurice Herlihy. The paper claims to represent just such an advance in concurrent programming, and so far I have not been able to find flaws in it.

There was a discussion on the Haskell mailing list about this topic in January 2005.

More information can be found in Kragen's concurrency bookmarks and in other people's concurrency bookmarks.