Прогнал) Одинаково) (см. аттач)

Это я понял  Но это, тем не менее, счётчик)

Это почему это он там не нужен? Он нужен и old выше уже объяснял почему необходимо лочить этот каунтер, дажеесли он атомарен..

Пусть счетчик был 0 и теперь, без всякой защиты, стал 1. В рез-те wait_for_all могло уснуть хотя должно было пробудиться. Но это ничем не грозит, когда-то счетчик обнулится и wait_for_all проснется.

Теперь здесь.

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

О том что лочить все подряд нехорошо мы уже говорили. Но здесь "защищать условие" нет смысла. Как только случился unlock, кто-то может сунуть задачу в очередь, m_task_count станет ненулевым, в рез-те wait_for_all не уснет или продолжит спать. Ситуация та же что и в первом случае - если пул пополняется со стороны, то можно потерять моменты когда он был пуст. Правда это ничем особым не грозит. Лучше так

C++ (Qt)
    template <class R>
    R wrapper_task(const std::function<R()> & task)
    {
        auto res = task();
        if (--m_task_count == 0)
            std::unique_lock<std::mutex> locker(m_mutex);
            if (m_task_count == 0) 
             m_cond.notify_one();
        }
        return res;
    }

Если пул хорошо "накормлен", то обнуление - случай редкий. Стандартный прием "двойная проверка" (за время когда брали мутекс все могло измениться).

Да, и опять забыл! Там небольшая помарка: в случае abort нужно отпустить ожидающего

Чтож.. Убедили, согласен  

Правда у меня Ваши тесты показывают +- одинаковые результаты

C++ (Qt)
const size_t WEIGHT_TASK = 64;
const size_t NUM_TASKS = 1024 * 1000;
const size_t NUM_PASSES = 8;
 
#define M_AX	0
 

Вывод:

Bash
pass 0
with std::futures<double>  result = -52.8008 total time (ms) = 5184
with wait_for_all  result = -156.814 total time (ms) = 5220
 
pass 1
with std::futures<double>  result = -66.3582 total time (ms) = 4875
with wait_for_all  result = -16.7101 total time (ms) = 5256
 
pass 2
with std::futures<double>  result = 209.773 total time (ms) = 4785
with wait_for_all  result = 137.421 total time (ms) = 5227
 
pass 3
with std::futures<double>  result = -109.539 total time (ms) = 4818
with wait_for_all  result = -311.828 total time (ms) = 5272
 
pass 4
with std::futures<double>  result = 64.4322 total time (ms) = 4721
with wait_for_all  result = -55.3244 total time (ms) = 5272
 
pass 5
with std::futures<double>  result = 141.65 total time (ms) = 4828
with wait_for_all  result = 272.018 total time (ms) = 5184
 
pass 6
with std::futures<double>  result = 7.6451 total time (ms) = 5081
with wait_for_all  result = -56.6884 total time (ms) = 5194
 
pass 7
with std::futures<double>  result = -171.047 total time (ms) = 4989
with wait_for_all  result = -130.11 total time (ms) = 5253
 
End
 

Да, насвистел.. Во-первых здесь:

C++ (Qt)
for (size_t i = 0; i < data.size(); ++i)
    {
        double val = dist(gen);
        data[i] = val * 2 - 1.0;
    }
 

нужно заменить на:

C++ (Qt)
 for (size_t i = 0; i < data.size(); ++i)
    {
        data[i] = dist(gen);
    }
 

а во-вторых, при таком WEIGHT_TASK = 64 такие флуктуации совершенно нормальны..

Всё же лучше так:

C++ (Qt)
void wrapper_task(const std::function<void()> & task)
    {
        if (task)
            task();
 
	#if M_AX
        std::unique_lock<std::mutex> locker(m_mutex);
        if (--m_task_count == 0) {
            locker.unlock();
            m_cond.notify_one();
        }
    #else
        if (std::atomic_fetch_sub(&m_task_count, 1) == 1)
        {
            std::unique_lock<std::mutex> locker(m_mutex);
            if (m_task_count == 0)
            {
                locker.unlock(); // <== делаем unlock перед пробудкой..
                m_cond.notify_one();
            }
        }
    #endif
    }
 

m_ax, а какой выигрыш принесли последние исправления?

Если вы замерите, сколько раз рабочие нитки упирались в заблокированный мьютес, то увидите, на сколько это редкий случай. У меня на машине для 10000 задач блок случался от 10 до 20 раз. И все эти ухищрения с двойными проверками не принесут даже 1% прироста.

Плюс современные мьютексы на основных платформах делают на футексах, которые при захвате свободного мьютекса бесплатны (это изменение атомарной переменной), дальше в зависимости от реализации может покрутиться  spin-lock, а только потом будет syscall в ядро на wait futex'а.

да