As I understand, in TBB we focus on task creation. The thread creation is taken care of by TBB internally. Now, if there is an error, what tools can I use to debug issues? The query is more specifically about understanding which threads created by TBB are being used for computation (in a loop or a task) and the others which could be status threads or that are sleeping or inactive. The problem statement is about understanding which threads to focus and which ones are causing issues? What kind of debugger that I can use?
a short answer is "all TBB worker-threads and the main thread participate equally in task execution and stealing". There is a way of excluding the main thread, but usually this does not happen (and it generally should not). So whenever you start a parallel_for algorithm (for instance) to work on your data you should expect that all threads from the thread pool will start sharing the work on processing the data. If there is an error (an incorrect result of data processing, for example) it does not mean that there is one single thread to blame. Tasks are being distributed (shared via stealing) randomly and any thread can become responsible for doing the "wrong thing". I'd say in that case you'd need a debugger with "data breakpoint" capabilities, where you can set a breakpoint to a certain change of your data, which corresponds to the faulty behaviour. Intel Parallel Debugger might be a good choice, since it now supports "data breakpoints" and supports debugging of multi-threaded applications. Another choice would be to look at your application through Thread Checker. TBB supports Thread Checker and while you will not see any TBB internals being analyzed, you might be shown a couple of data-race diagnostics in your parallel_for Body object. Data-races are often the problem that cause unreproducible incorrect results of a multi-threaded application run. Watch out for those!
A different case would be, when in addition to TBB worker-threads you yourself create native threads using TBB wrapper. In that case the error would not be happening inside parallel_for and you will have to analyze what that additional thread was doing that was so incorrect. Since this is a native thread you still could use Intel Parallel Debugger.
I understand that Intel Parallel Debugger is Intel product, and you are working for Intel, but... hmm... Intel Parallel Debugger integrates into MSVC and MSVC has data breakpoints for years... do you mean some more advanced features of Intel Parallel Debugger?..
The other way to get "data breakpoint" functionality (provided that you have access to source code) is to instrument code manually:
if (m_data == 13 and x == 666)
__asm int 3; // or __debugbreak() or __asm ("int 3") or whatever
You probably do not want to insert an int03, rather you may want to create and insert your own _ASSERT and then place your break point within the function dispatched to by the _ASSERT (the whole application has but one point break on assertions). You also want the assert handler to throw up a message box or some other means of notification should you forget to insert the break point. Also, write the assert handler such that you can set the next statement for execution to a location that will return (as opposed to aborting the app). This way you can have a better chance of figuring out the problem (or stepping past the problem while trying to figure it out).