ThreadPool PThread

Учитвая, что твой воркер держит мьютекс пока всё время пока запущенна полезная нагрузка, легко представить как твоя незатейливая диспетчеризация тупит ожидая этого мьютекса, а когда он освобождается, очередь ессно пуста.

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

И делать join в деструкторе - не очень хорошая практика (это как минимум не очевидно).

И зачем у тебя создаётся на куче твой пул? Что бы delete лишний раз вызвать?

Ну и оно вообще всё не exception safe. У тебя останется висеть мьютекс залоченным как минимум при броске исключения из функции. Раз уж пишешь сиё на крестах мог бы и простенькое RAII заюзать.

UPD. Ещё нет защиты от спонтанных просыпаний.

Что значит защита от спонтанных испытаний?

Прошу прощения, просыпаний))

man pthread_cond_wait

/Spurious

Ну и не по теме, но коммиты не на инглише, имхо таки фу фу фу.

Ну и не по теме, но коммиты не на инглише, имхо таки фу фу фу.

Если задача чисто учебная, которая после реализации будет успешно удалени, а читать код будут только рускоговорящие, то нормальный подход. Не нужно фанатизма. Для промышленного программирования это почти неприемлемо, для учебного примера - нормально.

Прост глаз режет :)

Более того - учебная задача, она во всём учебная, смысл учиться делать одно правильно а другое как попало?

пока делается реальная работа в методе run - лочится mutex. и соответственно getTaskCount ждёт mutex-а и соответственно getFreeWorker тоже ждёт, когда реальная работа закончится.