Community
cancel
Showing results for 
Search instead for 
Did you mean: 
applemax82
Beginner
396 Views

Does TBB support scalable thread pool

Hi,

I have found many free open source versions of thread pool, which are easy to use. For example, 

https://github.com/Pithikos/C-Thread-Pool and https://github.com/inkooboo/thread-pool-cpp

But I think TBB is more stable. Does TBB support scalable thread pool, where I can add any number of tasks into thread pool, and thread pool will add new threads to handle new tasks if there is no free thread at some time?

If TBB does support scalable thread pool, which sample code I can refer to?

Thanks!

Regards

Andrew

0 Kudos
5 Replies
Alexei_K_Intel
Employee
396 Views

Hi Andrew,

In my opinion, the question is too broad to answer because Intel TBB runtime library manages its own thread pool and can handle as many tasks as you want. However, it implements some sophisticated logic and limitations that can make it unsuitable for your needs. The main assumption of the Intel TBB thread pool implementation is that the tasks are compute oriented (e.g. not blocked for IO operations). So if you have many compute tasks feel free to use any Intel TBB interface (e.g. tasks, parallel algorithms, flow graph and so on) to utilize the internal thread pool. Nevertheless, if you want to use tasks for IO operations (e.g. files, sockets and so on) then Intel TBB tasking model is not good choice for it (although, you may want to consider some asynchronous APIs in flow graph like async_node for this purpose).

In any case, if you have any questions, feel free to ask.

Regards,
Alex

applemax82
Beginner
396 Views

Hi Alex,

Thanks for your quick reply.

The application I made is of flow graph, which is expected to create any number of flow graphs. The number of flow graphs depends on the environment.

There are lots of free open source versions of thread pool, where the thread number should be specified first. But in some cases, I don't how many threads should be used, and I don't like to create too many free threads that just waits for new tasks but don't do any work indeed.

If TBB has the capability of creating new threads dynamically according to the application requirement, my application is able to create and delete some flow graphs without having too many useless free threads that just wait.

Does TBB have this kind of function?

Thanks!

Regards

Andrew

Alexei_K_Intel
Employee
396 Views

Hi Andrew,

By default. Intel TBB runtime creates as many threads as available hardware concurrency. If you have tasks less than the hardware concurrency, the runtime will create more threads; however, the free threads will use OS-specific API not to waste CPU resource while waiting other tasks. So surplus threads will not impact overall system performance. This behavior allows Intel TBB runtime to process additional tasks efficiently and optimize CPU utilization (not to waste the resources).

As for flow graph, do you use the tbb::flow API or is it some other API?

Regards,
Alex

applemax82
Beginner
396 Views

Hi Alex,

I haven't decided which TBB API is used to make flow-graph program.

The ideal thread pool is expected, where the thread pool can add to some new threads dynamically and adaptively. My program create the thread pool, which creates n new threads at the beginning. In the middle, my program asks for more threads, and there are not enough threads for my program in the thread pool at the same time. It would be great, if the thread pool can add new threads to itself.

The reason that i want this function is, that each element in the flow graph should use one thread, and can't wait for other tasks to release their threads to the thread pool.

Is TBB able to ensure each element in flow graph has its own real thread?

Thanks!

Regards

Andrew

Alexei_K_Intel
Employee
396 Views

applemax82 wrote:

Is TBB able to ensure each element in flow graph has its own real thread?

No, it is impossible. However, could you clarify why do you need to ensure it? Do you want to use busy waiting inside each graph node? The flow graph API is designed to avoid busy waiting (because it is usually not a good approach), maybe, your algorithm can be restructured to rely on flow graph synchronization mechanisms. Or do you need mandatory concurrency in your application?

Regards,
Alex

Reply