The Challenge of Concurrency

June/July 2006

Concurrency is the biggest scandal in programming and it's time we did something about it. The scandal has existed for a long time but until recently it affected few people, since as a programmer you only needed concurrency if you were writing an operating system, a network controller or other such system-level software. The rest of us didn't have to worry about inadequate concurrent programming solutions -- only suffer the consequences when for no clear reason our machines hung and our connections broke.

Today what has changed for programmers is not the pain but how many feel it. If you flunked Concurrency 101 because you couldn't never get your Vs to match your Ps or wrap the right operations in conditional critical regions, then wisely kept the concurrency monster at bay by choosing a programming haven that you thought safe -- GUI, say, or financial software -- you won't be able to hide for much longer. Concurrency is coming soon to a program near you. Threads started it all: having found out that they can run several tasks at once in their browser, your users start demanding as much from other applications; but there's also the push to make every application network-aware and Web-serviceable. Those concerned with extreme performance can't miss the latest trend in hardware: continuing the advancement of Moore's law not through the electronics alone, but through concurrency at the chip level thanks to multicore architectures.

This brings us back to the scandal. The techniques to handle concurrency are not only older than object-oriented programming; they actually date from before the *previous* revolution. It's Dijkstra material, but a pre-structured-programming Dijstra. The standard way of handling threads and other concurrency, even with an object-oriented language, is through a library providing mechanisms such as semaphores, which in terms of abstraction level are somewhere with the Goto. The rest of the software uses data abstraction, information hiding, genericity, contracts, inheritance; the concurrency part is stuck in pre-modern history. It's like visiting Pompeii: most of what you see is contemporary people wearing denim shorts and waving 10-megapixel digital cameras; the multithreading part is like those hapless figures molded forever in the lava flow that caught them in action two thousand years ago.

Consequences of inappropriate concurrent mechanisms include "data races" (incompatible accesses to the same object, which one client is trying to access at the same time another is modifying it), deadlocks, and other trouble that is all the more damaging that it is usually non-deterministic: hard to reproduce and even harder to debug.

Kludges exist here and there but the only serious solution is to bring up the general practice of concurrent programming to an entirely new level of abstraction. Although the industry generally resists this idea -- for fear of the amplitude of the resulting cultural change from current ad hoc "thread libraries" and "memory models" -- there is a growing realization among researchers that we just can't go on with today's concurrency technology.

Various proposals are being floated for the concurrent mechanism of the future. In early July a conference in York (UK), CORDIE (Concurrency, Real-time and Distribution in Eiffel-like approaches, see http://www.artist-embedded.org/FP6/ARTIST2Events/Events/Cordie06/) was the opportunity for a comparison of a number of approaches around Eiffel. One of them, SCOOP, has been around for several years, but it's only now that SCOOP has a real implementation (http://se.ethz.ch/research/scoop), still experimental and already used successfully in teaching.

SCOOP as well as the other models presented at CORDIE are still evolving and you can expect considerable progress in the coming months. The conference provided the much needed impetus for the various teams to come up to speed with each other's designs. Many insights resulted from this confrontation of ideas.

No one knows which model (for Eiffel or otherwise) will emerge as the winner, but one thing is clear: with concurrency becoming the default mode in ever more areas of programming, we won't for much longer be able to rely on 1960s-vintage techniques. The race for a decent model is on.

-- Bertrand Meyer