progschj
possible deadlock during ~ThreadPool
condition.notify_all(); should be enclosed in the brack of unique_lock. This is to ensure that all workers are either waiting or executing while notify_all command is dispatched.
So as the enqueue() method:
std::future<return_type> res = task->get_future();
{
std::unique_lock<std::mutex> lock(queue_mutex);
// don't allow enqueueing after stopping the pool
if(stop)
throw std::runtime_error("enqueue on stopped ThreadPool");
tasks.emplace([task](){ (*task)(); });
} // here
condition.notify_one();
I don't see this causing a deadlock
All workers should not be within critical section when cv.notify_all is dispatched. Otherwise, the workers may miss the notify_all.
Although not notified, this->tasks is not empty, so it will not sleep the next time it enters thecritical section.
this is even what cppreference suggested: https://en.cppreference.com/w/cpp/thread/condition_variable I quote:
manual unlocking is done before notifying, to avoid waking up the waiting thread only to block again (see notify_one for details)
