Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Alignment of TBB and C++0x


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.
0 Kudos
1 Reply
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.