Возможно ли управлять распределением потоков по ядрам процессора?

#c #многопоточность #unix #freebsd

Всем добрый день!
 Рассматриваю возможности реализации нового сервера, и пока остановилась на модели
с созданием пула потоков. Однако поступила информация, что при такой работе сервера
на многоядерной системе, определенные потоки будут закреплены за ядрами сразу и перераспределения
их не будет, пока они не будут уничтожены, то есть возможна ситуация, когда часть пула
потоков, которая на данный момент никаких активных действий не производит, будет висеть
на одном ядре, и оно фактически будет простаивать, в то время, как второе ядро будет
загружено несколькими активными потоками. Если кто-то в курсе, подскажите плиз, действительно
ли это так, и есть ли какой-то способ управлять распределением потоков по ядрам, чтобы
загружать их более-менее равномерно? Может кто-то может полезной ссылочкой поделиться
применительно к unix - я ничего толкового пока не нашла по этому вопросу.    

Ответы

Ответ 1

Ручное распределение потоков по ядрам нужно только в очень исключительных случаях.
Система будет перераспределять потоки между ядрами, как ей кажется правильно. И может
перебросить рабочий тред с одно ядра на другое но в 99% это не нужно.
Давайте представим некую виртуальную систему с 16 ядрами и 100 потоками. и 10 из
них активно работает, занимая при это 10 ядер. Остальные 90 сидят тихонько на оставшихся
6. Вопрос, есть ли смысл перебрасывать активный поток на другое ядро? Ответ - нет.
Только хуже сделаем (накладные расходы на переключение). Поэтому система будет пытаться
сохранить поток на своем ядре.
Вариант, когда ядер 2 и 100 потоков (из них 10 активных). В этом случае загружены
будут точно два ядра. Причем выиграш от того, что есть 10 активных потоков будет отрицательный.
Именно по этой причине, когда создают пул потоков, которые нагружены одинаково, не
делают их больше кол-ва ядер+1. Потому что при дальнейшем увеличении кол-ва потоков
будет только падение производительности (накладные расходы на переключение. Процессор
только тем будет и заниматься, что переключать контексты потоков).
В случае одного ядра, не рекомендуется создавать более 16 потоков на процесс (это
конечно устаревшая информация, данная Борландом в году так 1995-1997 и в век двухядерных
процессоров у каждой домохозяйки в ноуте и в планшете она малоактуальна).
Но есть вариант, когда много потоков может улучшить задачу - это когда потоки занимаются
малоактивной работой. Но преимущество только одно - упрощается логика кода. Но это
сильно зависит от задачи.
А теперь подсуммируем. 

Если у вас сервер с 2 ядрами, то на
   данный момент это не сервер, а
   домашний компьютер.

Будете делать
   пул потоков - сделайте возможность
   регулировать кол-во потоков в пуле и
   проведите замеры. Очень часто,
   выставив правильное кол-во потоков,
   можно сильно ускорить задачу. А в
   некоторых случаях может выяснится,
   что оптимально будет работать только
   при одном потоке.
Не доверяйте русскоязычному переводу англоязычной документации. В спорных случаях
обращайтесь к английскому оригиналу. У меня был случай, когда из за неточностей в одно
слово в переводе мана по select смысл очень сильно менялся