1. В ОС тоже не факт. Если очередь сильно забита - ждать можно до бесконечности
2. В ряде ОС, насколько я помню, шедулер выдает ресурсы квантами по 50 ms, т.е. 200 активно работающих потоков x кол-во ядер = любую ОС положат.


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

Тут дилема. Переключение потоков процессов очень затратная операция и чем больше кэш процессора, тем затратнее и затратнее. Про NUMA архитектуру и Ethernet сети (RSS - receive side scaling) вообще можно не упоминать.

AFAIK OS и Java Runtime писатели уже > 10 лет пытаются что-то придумать, что бы при NUMA накладные расходы понизить, насколько я знаю, ничего не получается. До того не получается, что в Oracle соответствующую опцию как ввели в эксплуатацию, так через пару версий и вывели. В Java лет 5 назад читал отчет соответствующей группы, выводы у них были такие: 1. работа выполнена успешно, но положительный результат не достигнут (алгоритм реализован, но выйгрышь минимальный) 2. нашли багу в команде new, что она некорректно работает в многопоточке ))) там пол статьи было этой баге посвещено, что тип блокировки неправильный использовался )))

Т.ч. IMHO, даже 50 ms для ряда задач может быть крайне долго. Например при сетевом обмене и при неудачном стечении звезд, биндинг к процессорному ядру может задержки по сети в разы (!) улучшить.

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

IMHO & AFAIK. Но не думаю, что сильно ошибаюсь

А вообще, подозреваю, что в задаче автора усматриваю одну фундаментальную ошибку в постановке. Но предметной области не знаю, т.ч. могу и не правильно подозревать.

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

Они не идиоты, просто универсального алгоритма не существует. И по каким параметрам оптимизировать, тоже не понятно. Планировщик, в общем случае, пытается задачи по ядрам размазать; а всякие NUMA оптимизации, RSS и прочие совершенно наоборот, собрать однотипные потоки на одно ядро. А разница в задержках в некоторых случаях может и порядков, а то и нескольких порядков достигать.

AFAIK