Home » forums » LtU Forum

The PIllars of Concurrency

Herb Sutter, The Pillars of Concurrency, Dr. Dobb's Journal, 2007-07-02

In his inaugural column, Herb makes the case that we must build a consistent mental model before talking about concurrency.

When I first read the abstract, I assumed that Sutter meant a mental model along the lines of the pi-calculus. But it turns out what he was talking about has more to do with outlining the fundamental things for which concurrency is used, what requirements those things imply, and what kind of solutions can be used to meet the requirements. Nothing startlingly new, although the overview Sutter provides is interesting.

From a language design perspective, it might be interesting to consider which of the "pillars" that Sutter identifies are supported by a given language, how well, and why the language developed that way. Many of the arguments about the "best" way to handle concurrency may simply boil down to differences in the application domains being considered.

Also interesting to note is that much of this column was inspired by work by David Callahan on concurrency support for Visual Studio, so the things that Sutter discusses provide some insight into what Microsoft is thinking about for future development products.

By Allan McInnes at 2007-07-09 16:05 | LtU Forum | previous forum topic | next forum topic | other blogs | 10308 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Time to become a

Time to become a contributing editor, don't you think?

By Ehud Lamm at Mon, 2007-07-09 16:33 | login or register to post comments

Still blind wisemen

I believe that the three groups of concerns (pillars) are being presented in the article as more independent than they are.

Of course, separating concerns is useful for understanding them independently (analysis), but the problem arises when instead of careful subsequent sythesis the independent results are just bolted together. One ghastly example of this was misinterpretation of workflow patterns - some vendors just took these analysis tools as independent "components" resulting in toolbars literally hosting these patterns (imagine writing Java code by dragging "singleton", "composite", and "observer" from a toolbar).

By Andris Birkmanis at Tue, 2007-07-10 07:19 | login or register to post comments

Agreed

Agreed. I'm somewhat skeptical that the three "pillars" are as easily composable as Sutter claims. But having the three pillars broken out the way they are seems like it'd provide a useful starting point for thinking about which of the pillars it makes sense to support in given language (you might not need them all), as well as a framework within which to consider how well existing concurrent languages support the requirements embodied in a specific pillar. For example, software transactional memory is a neat idea, but some people are touting it as the ultimate answer to concurrent programming even though it emphatically doesn't provide any real support for "pillar #1" (or Joe Armstrong's notion of "modelling the concurrency of the problem).

By Allan McInnes at Wed, 2007-07-11 02:45 | login or register to post comments

Standard test cases

I think it would be a good idea to have as standard set of test cases for concurrency and distribution. These would capture standard patterns of use or problems , for instance "producer/consumer" ,"dinning philosophers" or “two phase commit”. I guess there would be about 50 or more. As workflow would be a part of that van der Aalst's http://www.workflowpatterns.com/ is a good start. This would mean all the myriad of competing systems and paradigms - pi calculus, join calculus, Eerlang, Transaction Logic, Coloured petri nets and so on (and on) could be compared.

By TheNextGuy at Wed, 2007-07-11 17:36 | login or register to post comments