Alignment of TBB and C++0x

[Michael_Uelschen]

Hello

I just started to consider the concurrency support in upcoming C++ standard. To my understanding there is some overlap in the functionality of TBB and C++0x (e.g. atomic operations, mutex, time measurement). Therefore I wonder what will be the future direction of TBB? Is there any idea to remove/align/wrap similar functionality from TBB? The current CP suggests that TBB will extend its functionality supporting high-level data structures.

Thank you.
--Michael

[Alexey-Kukanov]

Hello Michael,

you are correct to say that TBB will extend by proposing more of high-level components. As for coexistence of TBB and concurrency features of the upcoming C++0x, there are different levels to consider.

First, certainly it should be possible to use both TBB and C++0x atomics, locks, etc. independently of each other in the same program. I think there should be no problem even today, and if there are problems, please tell us and we will fix it.

Second, TBB provides some classes (thread, condition_variable) that implement C++0x functionality. We even inject the corresponding names into namespace std. It's mostly compatible with corresponding C++0x classes, but not 100%: we can't do 100% compatibilty without new features of the language, and also in some cases we deliberately choose incompatibility because otherwise we would have to implement a lot more classes and features not directly related to concurrency. The intended use for these classes is to ease migration to C++0x; so by default we switch it off if corresponding features are expected to exist (based on compiler version). I do not see a value in making these features 100% compatible in the future, but some changes can be done in case of user demand.

Third, there are features thatprovide the same or very close functionality but with different interface: atomics, tick_count, mutexes. Evolution of these features can go different ways, but backward compatibility with already written TBB code is the main consideration. For example, I do not expect TBB atomics to align with C++0x, but I can see us making TBB atomics implemented on top of C++0x, to ease porting TBB to more platforms. For mutexes, we may consider aligning with STL interfaces and deprecating our old interfaces, especially if our customers will ask for that. I do not expect tick_count to change; it's a small feature basically independent on the rest of TBB.

And fourth comes interoperability, i.e. the possibility to use C++0x concurrency features with high-level TBB interfaces instead of corresponding TBB features. Interestingly, I foresee almost no problems here, because the high level interfaces do not visibly depend on these low-level features. I searched the TBB Reference for "atomic", "mutex", "scoped_lock", and "tick_count", and besides correspondent sections of the Reference I only found thread and condition_variable (i.e. C++0x compatibility features) explicitly using it. Such cases as use ofC++0x atomics or locks in the bodies of parallel loops basically can be considered "independent", i.e. should work today.

That's basically how I see it. I'd be glad to have further discussion on the subject and learn other viewpoints.