Хм.. а чем не устраивает вариант, после того как воркер отрабатывает, отправлять его в слип на 10мс, к примеру? Проснулся - сделал работу - уснул.

Это понятно, но разве это не то, что хочет автор? Чтобы воркеры спали определенное время после завершения?

Хочет этого, но наверное и завершаться быстро тоже хочет.

Спать придется всей нитке. Во время её сна не будут приниматься события. Если воркеров будет достаточно много, оверхед на процессы засыпания/побудки не получится слишком большим?

Хотелось бы, чтобы диспетчеризацией кто-нибудь другой занимался, типа ОС . По предложенному:
1. Нитка 1 после 1-го пункта спит по QWaitCondition::wait?
2. Нитка 2 посылает сигнал по wakeOne?

1) Нет, тупо sleep.
2) Нет, просто проснулась - шлет сигнал с QueuedConnect и опять повисает на своем EventLoop

Да, это самопальный таймер, но с той разницей что ОС не может его "задвинуть взад" как он любит делать. Если время sleep значительно - порезать, напр

C++ (Qt)
while (sleepMs > 0) {
 int step = qMin(sleepMs, sleepStep);
 sleepMs -= step;
 if (abortFlag) ...
 sleep(step);
}

В смысле всей нитке? Если каждый воркер - это отдельная нитка, то спать и просыпаться будет только он сам.

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

У нас другая неприятность как-то была - по-разному отрабатывали треды, созданные через QThread, и треды, созданные через WinAPI, в разных осях (в 7 и 8 ), насколько я помню.

И все-таки, Hyperthreading пробовали выключить?

Не пробовал, думаю что не поможет. Если настаиваете - попробую. Просто всё "разломал" уже: от таймеров избавился и переделал на invokeMethod, там всё работает более предсказуемо.

На Windows Server пробовал в виртуалке на десктопном железе - работает нормально.

"Просто" работает. Даже в моём варианте из 20 ниток 17 стартуют нормально .