The Pillars of Concurrency
By Herb Sutter
– –
In his inaugural column, Herb makes the case that we must build a consistent mental model before talking about concurrency.
Herb is a software architect at Microsoft and chair of the ISO C++ Standards committee. He can be contacted at www. gotw. ca.
– –
Quick: What does “concurrency” mean to you? To your colleagues? To your project?
You probably know the fable of the blind men and the elephant: Several blind men explore an elephant by feel, and each one draws his own conclusion about what the elephant is. The man at the tail concludes that the elephant is like a rope; the one at the tusk asserts that, no, the elephant is like a spear; the one at the leg thinks it’s like a tree; the one at the ear that it’s like a fan; and so on. The blind men argue, each one knowing he is “right” from his own experience and point of view. In time, several give up hope of ever agreeing on what the creature is, and some resign themselves to accepting that the best they can do is deeply analyze each disconnected part in isolation as its own separate self. Meanwhile, the poor elephant waits patiently, faintly puzzled, because of course, it is not like any of those things alone and it doesn’t see itself as that hard to understand as a whole creature.
Have you ever talked with another developer about concurrency, and felt as though you were somehow speaking completely different languages? If so, you’re not alone. You can see the confusion in our vocabulary (and this is not an exhaustive list):
Acquire, and-parallel, associative, atomic, background, cancel, consistent, data-driven, dialogue, dismiss, fairness, fine-grained, fork-join, hierarchical, interactive, invariant, isolation, message, nested, overhead, performance, priority, protocol, read, reduction, release, structured, repeatable, responsiveness, scalable,
schedule, serializable update, side effect, systolic, timeout, transaction, throughput, virtual, wait, write,…
Some of the words have many meanings (performance, for instance), while others are unrelated (responsiveness and throughput, for example). Much of the confusion we may encounter arises when people inadvertently talk past each other by using incompatible words.
A basic problem is that this shouldn’t be a single list. But how can we group these terms sensibly, when experienced parallel programmers know scores or hundreds of different concurrency requirements and techniques that seem to defy grouping?
Callahan’s Pillars
My colleague David Callahan leads a team within Visual Studio that is working on programming models for concurrency. He has pointed out that fundamental concurrency requirements and techniques fall into three basic categories, or pillars. They are summarized in Table 1 [1]. Understanding these pillars gives us a framework for reasoning clearly about all aspects of concurrency – from the concurrency requirements and tradeoffs that matter to our current project, to why specific design patterns and implementation techniques are applicable to getting specific results and how they are liable to interact, and even to evaluating how future tools and technologies will fit with our needs.
Let’s consider an overview of each pillar in turn, note why techniques in different pillars compose well, and see how this framework helps to clarify our vocabulary.
(No Ratings Yet)