Can anyone explain the relationships among TBB, compilers, OSs and processors? I mean what exactly each part does to makethe programmingbenefit from multi cores. The question may seem simple, but I think it is this simple question that makes it hard to get TBB more generic and compatible.
TBB is only one of several viable (according to your application and programming language)multi-core programming methods. It combines the ideas of STL and OpenMP to provide an interface to a threading library to be linked to compiled code. Like those, it aims to relieve the programmer of the details of making the application work with each compiler and OS combination.
Language standards dictate the extent to which the programming language supports multi-programming (very little, for C++ itself). The division of responsibility between a library such as TBB, the underlying threading library, and the OS, is negotiable to some extent, but cannot normally be the concern of the software developer.
Thanks for the explanation. Although multi-core libraries try to releive programmer from the concern of compatibility,they are facing the compatible issues themselves. I think this is the reason why TBB lists all the supported processors, OSs, compilers, etc. As a programmer, normally you don't need to worry about such issues as long as you are able to build theprogramming and testing platform and keep your development going. But as an end user, you may encounter different issues when installing the program for multi-core. Sometimes, end usersare not even able to get their OS running on multi-core hardware. Although the OS itself doeshave multi-core feature. As a result, programmers or at least designers need toget some idea hidden behind the library. For example, if a new multi-core chip is supported by an OS which is in the compatible list of TBB, does this mean this chip can totally be supported by TBB? Another question is why TBB cannot support some OS which does support multi-core. What's the difficulty there? So it'd be greatly appreciated if anyone can give out an relationship mapof all steps from the source codes, TBB to the final executable file as detailed as possible and clear enough to explain why TBB cannot yet support some other OSwhich has multi-core feature. This may be very helpful when programmers have to face the questions from end users about compatible issues.
TBB also uses low-level threading support from the O.S. in the form of POSIX threads or Microsoft Windows threads, and for Linux it also does something with futex, but it should be relatively easy to port to a similar API if POSIX threads are not available (I did this for Solaris threads once, but that has little practical relevance because Solaris has had POSIX threads as well since quite some time).
Otherwise, you'll need GNU make and/or whatever build infrastructure your O.S. uses, and an adaptation of the build files to the platform you are using. For example, I changed the "machine" stuff above to support 32-bit PowerPC (since recently also with 64-bit atomics) and SPARC, but I have not yet built all
(Paradoxically, compiling TBB currently does not make use of multiple cores, because GNU make doesn't.)
"For example, if a new multi-core chip is supported by an OS which is in the compatible list of TBB, does this mean this chip can totally be supported by TBB?" You'll need to write some assembler code first.
"Another question is why TBB cannot support some OS which does support multi-core. What's the difficulty there?" Does it have POSIX threads? Does it have GNU make? If so, you can just add some files in build/, modified from a similar O.S., otherwise it will be a bit more work.
See "build directions" and "build" links in index.html in the source distribution for some details.
Do you have any concrete purpose beyond this abstract concern?
Thanks for such detailed explanations. Actually I have no concrete purpose. I was just wonderinghow much TBBgets involved with processors andhow to avoid compatible issues for the systems in the past or in the future.As computer systems are getting more and more complex and diversified, compatibility is more sensitive and important. Thanks again for your information.