I need that because I usually update a progress bar only on the master thread.
TBB does not have a get thread ID equivalent purposely, to discourage code dependence on specific threads or specific numbers of threads. Programs written tospecific thread counts have the potential to lock in scaling to that number and may require rework to handle newer computers. In TBB's philosophy, the programmer's task is to worry about concurrency and dependence and the user-scheduler's task is to worry about best to schedule those tasks.
That said, you learn how to implement a thread ID in TBBby looking at my blog post, which contains an example using task_scheduler_observer to create a thread ID.
I really don't need the threadID. I currently use it just to update a progress bar: only the thread #0 should do this because each time I update the progress bar is takes some time... and atomics/critical sections could make it even slower... I don't need a super-smooth progress notification ( my tasks could take minutes so the progress bar is just indicative... it does not need to very very precise ).
Do you know a method using TBB to perform this efficiently?
As you only need a thread ID to identify your master thread (as opposed to numbering all threads in a parallel region), I think that this_tbb_thread::get_id() will suffice. It is essentially a wrapper over system-specific calls such as GetCurrentThreadId or pthread_self, so it works for every thread including masters and workers. The IDs returned by this function can be stored and compared to each other.
__declspec(thread) bool isMain = false;
isMain = true;
tbb::.... // start TBB here
Now, the TBB thread pool thread that was the main thread is the only thread containing true.
*** caution ***
This requires the main thread to be one of the threads used in TBB.
volatile long nextThreadID = 0;
__declspec(thread) longmyThreadID = -1;
// somewhere in your code
if(myThreadID < 0)
myThreadId = InterlockedExchangeAdd(&nextThreadID, 1);
if(myThreadID == 0)
Above requires that at some time your "master" thread runs throug the above section of code.
Therefore, the above needs to be placed at some point in your code whereall threads will call periodically. Perhapse in a routine that tests forsignificant event. So you may have additional overhead if you cannot insert this into some innocuous place.
Some graphics libraries go nuts if the calling thread is not the thread that initialized the display. Therefore, the thread that initializes the display may have to be the TBB thread that elected itself "master" (2nd method).
If you init prior to starting TBB (and use 1st method), then you may have to examine how your version of TBB starts its thread pool. Many PThread implementations, the main thread goes idel after starting its thread pool. As to what TBB does (on all platforms) I cannot say. Do not assume all implementations of TBB will do the same as the one you first test your code on. Windows may do it one way, Linux may do it a different way.