Should theadpool create and destroy threads dynamically?
Opened this issue · 3 comments
Current threadpool in this project creates threads statically when it is initialized. And number of threads is fixed during its lifecycle.
Why not create and destroy threads dynamically?
Create:
- case 1: number of current threads is less than number of core threads.
- case 2: number of current threads is less than number of max threads, and no idle threads exist now.
Destroy:
- thread has waited for
keep_alive_timetime interval without jobs fetched.- core threads can ignore
keep_alive_timeand keep alive if allowed.
I think the whole point of a thread pool (statically created threads at init time) is to avoid the overhead of creating/destroying threads repeatedly during run time. The penalty for having idle threads in the background is basically none, so it's not worth the effort to destroy them.
I think the whole point of a thread pool (statically created threads at init time) is to avoid the overhead of creating/destroying threads repeatedly during run time. The penalty for having idle threads in the background is basically none, so it's not worth the effort to destroy them.
Sure, creating/destroying threads may bring some overhead, but is it significant performance overhead？It may be difficult to estimate each workload when creating threads statically. Too many static threads may waste resources, and too few threads can not deal with tasks well. That is why I think it is meaningful to create/destroy threads dynamically.
Late to the party but my two cents
Other than the fact that dynamically allocating the threads would make this not a thread pool: embedded applications and other applications where heap space and cycles are severely limited exist, and using malloc in many codebases is frowned upon. The main point of a threadpool is that you can have a sort of fake dynamic allocation depending on how many jobs come through, because malloc and free are very expensive operations compared to leaving a thread idle.