C++0x Concurrency Support and TBB

C++0x Concurrency Support and TBB

Hey,

I attended a presentation today on concurrency within the upcoming C++0x standard. How will this upcoming standard affect the implementation and use of TBB?

The seminar presented a position of Hans Boehm, that a C++ library just won't cut it for concurrency, that the language itself must provide support. I have to read more on this position to understand it, but personally I favor the library approach with my current level of ignorance of his work.

We also discussed a problem which I never realized existed before, "speculative writes" whereby the processor or compiler could re-order instructions to bypass a call to a mutex and thus accidentally cause incorrect parallel code.

Personally I left the seminar with my personal opinion that concurrency should be left out of the standard, and left to libraries (I admit I have to read more, my opinions do change). I also felt a lot of the concurrency issues being tackled were premature... we have discussed on this forum how STL is inherently serial, aside from some special functions which have parallel implementations.

Now for my actual TBB questions. One is, how is the issue of "speculative writes" solved with TBB? How could the TBB project be affected by concurrency within the C++0x standard? Is it simply the case that low-level details within TBB would be replaced with C++0x standard features over time?

In a world with concurrency provided by C++0x, how will TBB fit in?

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hans Boehm, the fear mongerer... :-) I've been giving this some thought myself, and one of the issues on the table right now would be that atomic load and store operations probably need a full fence by default (not just acquire and release as currently implemented by TBB), but there my (original?) idea would be that maybe instructions' crossing of fences should be disallowed between even asymmetric fences (although I don't know if that's just of whack-a-mole relevance or a bit more than that, and how relevant it would be on current hardware). I suppose processor-initiated speculative writes of the kind you mention would be subject to cache coherency hardware protection, and that the compiler would be forbidden to do things like that unless explicitly given permission, which would make that problem at least irrelevant for TBB. But I have some more reading to do before I can really take position on library vs. no library, although it seems to me that the standard should try to limit itself to enabling a library approach.

Leave a Comment

Please sign in to add a comment. Not a member? Join today