По хорошему join дожидается, когда реально завершатся рабочие нитки пула.
У меня в конструкторе пула нитки запускаются, в деструкторе завершаются и joinом контролируется завершение. А все время жизни пула нитки активны или ждут работу.
А вот завершение конкретной задачи можно ждать по разному: футурами, callbackами или просто на них забить.

Как я делаю ожидание в рабочих нитках:

C++ (Qt)
  void	thread_run()
  {
    for(;;)
    {
      std::unique_lock<std::mutex> locker( m_mutex );
      for(;;)
      {
        if( m_stop )
          return;
        else if( !m_tasks.empty() )
          break;
        m_cond.wait( locker );
      }
 
      Task task = m_tasks.front();
      m_tasks.pop();
 
      locker.unlock();
 
      if( task )
        task();
    }
  }
 

Завершение ниток:

C++ (Qt)
  ~ThreadPool()
  {
    {
      std::unique_lock<std::mutex> locker( m_mutex );
      m_stop = true;
    }
    m_cond.notify_all();
 
    for( auto &it : m_threads )
      if( it.joinable() )
        it.join();
  }
 

Устанавливать m_stop в true нужно обязательно под мьютексом, а вот сигналить лучше уже без него.

Блин, случайно отредактировал этот пост, вместо цитирования. Придется набирать заново.

Хочу более подробно расписать почему так думаю.

Устанавливать m_stop необходимо обязательно под мьютексом.
Потому что может возникнуть ситуация, когда рабочая нить уже прошла проверку флага m_stop, но еще не уснула на wait, тогда установка m_stop и сигнал из другого потока никакого эффекта не вызовут - нитка уснет на wait.
А если устанавливать m_stop мод захваченным мьютексов, то нить завершающая пул остановиться на захвате мьютекса, пока рабочая нить его не освободит, уснув на wait.

А сигналить лучше без захваченного мьютекса, потому что на многоядерных системах планировщик сразу пытается запустить ожидающую (на wait) нить на свободном ядре при сигнале условной переменной.
Если сигналить при захваченном мьютексе, то разбуженная нить попытается захватить мьютекс, но он захвачен сигнальной ниткой. Рабочая нить уснет в ожидание мьютекса и проснется опять после его освобождения.
Т.е. будет дополнительная усыпление рабочей нитки.

Old, я правильно понимаю, что если я всё же хочу заиметь метод wait_for_all (который блокирует поток, где он был вызван и ждёт пока все рабочие нитки опустошат очередь) то нужна ещё одна condition_variable? Вот что у меня сейчас получилось (вроде работает ):

C++ (Qt)
class thread_pool
{
public:
    explicit thread_pool(size_t num_threads = std::max(size_t(1), size_t(std::thread::hardware_concurrency())))
        : m_stop(false)
    {
        for (size_t i = 0; i < num_threads; ++i)
            m_threads.emplace_back(&thread_pool::worker, this);
    }
 
    thread_pool(const thread_pool &) = delete;
    thread_pool(thread_pool &&) = delete;
 
    thread_pool & operator=(const thread_pool &) = delete;
    thread_pool & operator=(thread_pool &&) = delete;
 
    ~thread_pool()
    {
        {
            std::lock_guard<std::mutex> locker(m_mutex);
            m_stop = true;
        }
 
        m_cond.notify_all();
 
        for (auto & th : m_threads)
        {
            if (th.joinable())
                th.join();
        }
    }
 
    void wait_for_all()
    {
        std::unique_lock<std::mutex> locker(m_mutex);
        m_cond_wait.wait(locker, [&]() { return m_queue.empty(); });
    }
 
    template<class F>
    auto add_task(F && f)->std::future<decltype(f())>
    {
        using R = decltype(f());
 
        auto task_ptr = std::make_shared<std::packaged_task<R()>>(std::forward<F>(f));
 
        {
            std::lock_guard<std::mutex> locker(m_mutex);
            m_queue.emplace( [=]() { (*task_ptr)(); } );
        }
 
        m_cond.notify_one();
 
        return task_ptr->get_future();
    }
 
private:
    std::atomic_bool m_stop;
    std::list<std::thread> m_threads;
    std::queue<std::function<void()>> m_queue;
    std::mutex m_mutex;
    std::condition_variable m_cond;
    std::condition_variable m_cond_wait;
 
    void worker()
    {
        for(;;)
        {
            std::unique_lock<std::mutex> locker(m_mutex);
            m_cond.wait(locker, [&]()
            {
                return !m_queue.empty() || m_stop;
            });
 
            if (m_stop)
                return;
 
            std::function<void()> task(m_queue.front());
            m_queue.pop();
 
            locker.unlock();
 
            if (task)
                task();
 
            m_cond_wait.notify_one(); // <== Эта условная переменная для wait_for_all 
        }
    }
};
 

Или нафиг его выпилить вообще?)

update: Нет, этот метод ждёт только пока очередь не пуста, но не момент когда все нитки отработали..(

update2: Вобщем я его всё же выпилил.. Не нужно усложнять то, чего того не требует..

Вспомнил еще один аргумент в пользу этого тезиса.
Утилизация горячего воркера. Нам очень выгодно, если нитка выполнив одну работу, делает цикл и забирает следующую без пауз на мьютексе/условной переменной.
Если мы сигналим под мьютексом, то нитка которая только что освободилась не сможет захватить мьютекс и достать новую задачу.
Произойдет следующее: горячая нитка уткнется в мьютекс, шедулер разбудит холодную нитку (ждущую на wait), начнется гонка за мьютекс и может получиться так, что горячая нитка не спеет забрать новую работу и будет успылена на wait, а разбуженная пойдет работать.

Так вы все обещали показать чудо-решение на атомиках, но не получается, хотя все уже готово.

Моя задумка была обойтись без счетчика задач, т.е. сохранить весь ф-ционал пула но добавить WaitForDone. Со счетчиком жить легче, Ваша реализация подлиннее зато "не интрузивна", в чем есть смысл

C++ (Qt)
    void wrapper_task(const std::function<void()> & task)
    {
        if (task)
            task();
 
        std::unique_lock<std::mutex> locker(m_mutex);
        if (--m_task_count == 0)
        {
            locker.unlock();
            m_cond.notify_one();
        }
    }
};
 

Брать еще мутекс для каждой выполняемой задачи - ну так мы признаем что делаем лишь для "хороших" задач. Брать мутекс надо после атомарного декремента, это случится редко. А поскольку мутексу некого засисять то он здесь вообще не нужен. Также и в методе add_task - еще мутекс, ведь у m_pool есть свой. Оно конечно неопасно поскольку обычно главная набивает пуд, но все-таки нехорошо.

Но это совсем не вина тестов Там есть TASK_WAIT, попробуйте его увеличить, все станет хорошо с QThreadPool. Но на мелких задачках ужасный провал (ото видать насовали мутексов). А юзать QThreadPool "с оглядкой" страшно неудобно. Более того, выясняется что даже простейшая самопальная реализация пула ведет себя гораздо лучше. Вот вам и "готовые проверенные" 

Кстати а Вашу "футуристическую" реализацию не хотите прогнать на этих задачках?