К вопросу об организации взаимодействия пула производителей и одного потребителя

[m_ax]

Т.е. для каждой конкретной задачи, должен ставится вопрос:  а нужно ли её распараллеливать, и если нужно, то как наиболее эффективно..

[Old]

Ну я, специально, этот случий не расматривал.. Хотя, в общем, это не сложно посмотреть.. (Посмотрю)

Я хотел сказать, что в подавляющем большинстве случаев мьютекс будет свободен.
Ваши "оптимизации" с двойной проверкой могут стоить дороже вашего первоначального варианта. Точнее в варианте с ожиданием завершения всех задач это не будет иметь роли, а вот если такие "оптимизации" применять в постоянно исполняемом коде, то может быть медленнее.

Современный мьютекс это атомарная переменная и пытаться ускорить ее использованием другой атомарной операции не всегда удается.

[m_ax]

Я хотел сказать, что в подавляющем большинстве случаев мьютекс будет свободен.

Что значит в подавляющем большинстве случаев?

Да, я согласен, что если вот так, как в предложенных тестах, кидать "мелкие" задачи, то мы неменуемо свалимся в  bottlen neck эффект (эффукт узкого горла - пробка)
Ну даже тут вариант с футурами проходит 

Я не хочу в продакшен выкидывать wrapper_pool, поскольку оно спорно..(Но это обсуждаемо )

[Igors]

       if (std::atomic_fetch_sub(&m_task_count, 1) == 1)

Я пользуюсь атомарным инк(дек)рементом уже не один десяток лет. Не верите - ну страхуйтесь Вспомнилось неплохое объяснение типа:

Атомарная арифметика оперирует/возвращает "моментальные фотографии". Т.е. то что "изображено на фото" - правда, реальный факт который "имел место". НО когда мы получили это "фото" мы должны иметь ввиду что это "уже в прошлом" и могли произойти др события. На первый взгляд в этом нет смысла - ведь возвращенному значению все равно "нельзя верить", оно могло уже стать иным. Но "факт" можно использовать как в примере выше. И факты эти случаются строго один за одним (за счет отой "ordered memory semantic"), а вот какая нитка получит какое фото - уже как фишка ляжет.

Ну даже тут вариант с футурами проходит 

Да какой там "вариант", просто "так заработало" Зачем нужен контейнер если можно обойтись счетчиком? 

- А почему Вы ищете только под фонарем?
- Потому что там светло

Да, я согласен, что если вот так, как в предложенных тестах, кидать "мелкие" задачи, то мы неменуемо свалимся в  bottlen neck эффект (эффукт узкого горла - пробка)

Дело не только в "мелких задачах". Вы набиваете пул по самые "не балУйся" - но это "хороший" случай, а в жизни часто не так - напр нужно нужно сначала посчитать всего с десяток задач, "осмотреться", потом еще десяток-другой и.т.д. (в тестах что я выкладывал это есть). Здесь постоянное усыпление/пробуждение ниток обходится дорого.

Т.е. для каждой конкретной задачи, должен ставится вопрос:  а нужно ли её распараллеливать, и если нужно, то как наиболее эффективно..

Да-да-да В жизни происходит примерно так

- во, тут превью совсем дохнет, 2-3 fps. Ладно, профайлим - ага, жрется на пересчете нормалей. Отключаем это место - во, 70 fps. На GPU не перенести. А "задача" здесь - получить 2 вектора вычитанием и записать в рез-т векторное произведение. До того atan2 там ой далеко. Ну и понеслась...

Вообще, в идеале, хотелось бы реализовать идею cpp-taskflow https://github.com/cpp-taskflow/cpp-taskflow
Понравилась мне она очень 

Так, чисто для удовлетворения своих эстетических чувств) К тому же я могу себе это позволить)

А конкретнее? Те картинки мне, правду сказать, и нафиг не нужны. А если что интересное - поддержу обсуждение, только тему новую создайте

[Old]

Я не хочу в продакшен выкидывать wrapper_pool, поскольку оно спорно..(Но это обсуждаемо )

m_ax, по моему мнению нет особого смысла в подобных "оптимизациях":

Код

C++ (Qt)
#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
 

Это либо ничего не ускорит, как в данном случае, а может и ухудшить.
Я это хотел сказать.

[Old]

Я пользуюсь атомарным инк(дек)рементом уже не один десяток лет.

Я думаю сотни.

[Old]

Я не хочу в продакшен выкидывать wrapper_pool, поскольку оно спорно..(Но это обсуждаемо )

Этот враппер можно положить в примеры.

По поводу "толстоты" future...
future это указатель на приватную структуру promise, т.е. если вы используете packaged_task, то вы их и так создаете.
Внутри promise использует тот же атомик + futex, т.е. весит она атомарную переменную + хранилку для результата (если он есть).

Ну а дальше сами (или пользователи пула) решайте, хранить массив futur (массив указателей) или нет.