Home

Concurrency: The Compiler Writer's Perspective

A short interview with Brian Grant (of PeakStream and currently Google). From SD Times, Nov. 15, 2007.

SD Times: Is concurrency too difficult for developers accustomed to linear programming to grasp?

Brian Grant: It is challenging, but I don’t think it’s too challenging. I do think certain languages, especially C and C++, make it very challenging to write robust big multithreaded systems. Basically, they have features that are hostile to concurrency.

Does your experience in compilers give you a different perspective than the average developer?

[...]
Higher-level languages favor ease of correctness over ease of performance. For example, in functional languages such as Haskell, the code you write does not have any side effects. The model is that they don’t modify existing data; they generate new data. The advantage is that it’s easier for the compiler to reason about what different components of the code can do.
[...]

By Tommy McGuire at 2007-12-04 19:17 | Implementation | Parallel/Distributed | other blogs | 8487 reads

Comment viewing options

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

In the case of C++ (and to

I think Brian understates the problems with C++: in the case of C++ (and to some extent C), the biggest issue is that the language is underspecified with respect to concurrency, and in some cases the language semantics actually conflict with the semantics required by platform threading APIs like POSIX threads.

As he says, the next version of the C++ specification should address this, but we are a long way away from widespread implementation. I wouldn't really want to be trying to write robust multithreaded software in C++ today.

By mental at Wed, 2007-12-05 17:00 | login or register to post comments

How about sharing some links

How about sharing some links to C++ specification work in this area, if you got them?

By Ehud Lamm at Wed, 2007-12-05 17:49 | login or register to post comments

C++ standards work

Most of the threading related work is covered in these papers:

  • N2429 -- Concurrency memory model
  • N2427 -- Atomic types and operations
  • N2447 -- Multi-threading library

From the standards committee's public reports, it appears that those are expected to be incorporated largely unchanged into the 2009 edition of the C++ standard.

By Ross Smith NZ at Wed, 2007-12-05 18:31 | login or register to post comments

Thanks!

Thanks!

By Ehud Lamm at Wed, 2007-12-05 18:33 | login or register to post comments

C++ memory model

The draft standard prohibits speculative loads/stores. N2338 discusses some of the consequences to compilers. The Linux kernel and gcc mailing lists have had several recent threads on this topic.

By dbremner at Mon, 2007-12-10 19:26 | login or register to post comments

Certainly!

I can't really outdo Hans Boehm's giant page of C++ memory model links, so I'll start there and highlight some important ones.

The Problems

Hans' paper, "Threads Cannot be Implemented as a Library" was previously discussed on LtU; it highlights the sort of language extensions necessary for reliable multithreaded programming with C++.

Another must-read is Nick Maclaren's "Why POSIX Threads Are Unsuitable for C++", which highlights actual incompatibilities between the C++ language and POSIX threads.

The Specification Work

Overview slides about the C++ memory model effort.

Nick Maclaren's "Generic Support for Threading Models"

Edit: redacted links to proposals since Ross' are more current.

Also, a video of a talk by Lawrence Crowl about the specification work. Hans Boehm has been delivering a more recent talk entitled "Getting C++ threads right" (just last month), but I'm not aware of it being online anywhere yet.

By mental at Wed, 2007-12-05 19:06 | login or register to post comments