Hello, I recently updated my TBB to the current version
I use tbb::task_scheduler_init::default_num_threads() to intialize the task scheduler.
This is called once on the main thread.
This value is 8 on my computer.
I also spawn 2 slow-task threads(File IO etc) using the std::thread pulled in from #include "tbb/compat/thread"
Previously this resulted 1 main thread + 7(or 8?) TBB worker threads + 2 slow tasks threads as expected..
Now I am having an issue where TBB is spawning more and more worker threads.
I'm seeing 10-12 etc.
Why is TBB doing this? And how can I prevent it from doing so?
Is it related to the slow-task threads?
If they call TBB, does TBB decided they also need worker threads? If that is the case, can I make them all share the same pool of workers?
Yes there are 10-12 running at the same time(perhaps some are suspended, but all exist at once), although it seems inconsistent.
I can see them in Visual Studio 2017 threads view, and checked that each was indeed spawned by TBB.
Also I have a thread local ID which I assign to TBB worker threads, and this number is now also going above the expected count.
I do not know what triggers it, it seems somewhat inconsistent as to when/if it will happen--it does not happen immediately, often it is about 20-30 seconds after the program started(many thousands of tasks will have already been run)
For reference, the TBB I have is:
Intel TBB 2017 Update 5
TBB_INTERFACE_VERSION == 9105
Prior version was:
TBB 4.0 commercial-aligned release
Yes that appears to be the same issue, I was not aware that TBB would ever create more threads than the number passed into the scheduler.
I am doing something similar to the poster in that thread, I assign pools of memory to each TBB thread, which was why it was an issue.
I'd like to be able to set a hard limit on thread count, but for now I will adopt the code to deal with TBB creating extra threads--
Or do you really observe more threads than expected working simultaneously at the same time?
Well there were more threads than expected alive, which was the issue(initially it would crash as the code was not expecting this, now it just causes extra memory pools to be created) .
When I paused the app to see the TBB threads call stacks, I could see 10-12 TBB worker threads, some were working on tasks, some were suspended waiting for more work to arrive.
Intel TBB runtime can create more threads than requested but the number of threads participating in some work will never exceed the limit. You can use the local_observer functionality to manage memory accurately.