is a shared pointer to std::thread a bad practice?

Question

Does it make sense to use std::shared_ptr < std::thread> ? The logic is simple: if thread is not needed, delete it, if new is required - realocate it. is there any way to compare this concept with pooled threads?

I do know the exact ammount of threads in my system(I develop Image processing algorithm, and I wanted to give each child of "algorithm" class an individual thread (maybe to make it private, then no shared_ptr is required), where this algorithm will be running, and idle this private thread if no image was provided. Is it a bad concept?

Answer 1

You probably miss the fact fact std::thread destructor does not terminate the thread. As already mentioned in the comments, if detach or join was not called before, std::thread destructor calls std::terminate. In other words, std::shared_ptr<std::thread> is pretty useless.

A std::thread is a rather low-level object. You may like to have a look at:

• Non-blocking I/O threads.
• Thread pools for blocking tasks and computations, like Intel TBB Task Scheduler.
• C++17 Extensions for parallel algorithms, or libraries like Intel Parallel STL.

Answer 2

This answer is in the question:

give each child of "algorithm" class an individual thread (maybe to make it private, then no shared_ptr is required)

Only use std::shared_ptr<> where ownership is genuinely shared.

There's usually no harm in idle threads hanging about but on many systems there is an overhead of even a ceiling on thread instances even if many are not running.

If there's a risk of thread proliferation or too much creating and destroying of threads and swapping, introduce a thread-pool and still don't use shared_ptr<> because the pool with own the threads.