possible deadlock during ~ThreadPool

[ShunlongHu]

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.

[ShunlongHu]

[faywong]

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();

[XiaomingQu0913]

I don't see this causing a deadlock

[ShunlongHu]

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.

[XiaomingQu0913]

Although not notified, this->tasks is not empty, so it will not sleep the next time it enters thecritical section.

[Toby-Shi-cloud]

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)