Стоимость использования select () в разных потоках для одного и того же процесса

Question

В моем приложении я начинаю использовать вызов select() в нескольких местах, отслеживая разные вещи в моем процессе (сетевые соединения, IPC, обмен сообщениями, файлы ...).Все вызовы используют их собственный набор файловых дескрипторов, что означает, что ни один дескриптор не используется дважды при выборе.

Это означает, что иногда у меня есть что-то вроде 5 select() блокировок вызовов вразные потоки.

Существует ли снижение производительности при использовании select() несколько раз в разных потоках вместо, может быть, использования только одного вызова и отправки результатов в соответствующие потоки?

На самом деле, существует ли ограничение на число select() вызовов, ожидающих одновременно?

Существует ли инструмент для измерения этого?

Поскольку приложение может растиеще больше, я подозреваю, что в какой-то момент, если это станет проблематичным, мне придется кодировать какой-то централизованный select(), который собирает все FD для мониторинга и уведомляет клиентские потоки, когда данные готовы для сбора / записи.

Так что я решил, что лучше спросить раньше ...

Answer 1

Маловероятно, что вы заметите разницу в производительности.

Внутри ядра select добавляет ваш поток в «очередь ожидания» для каждого дескриптора, который вы выбираете, и переводит его в спящий режим. Если вы выберете дескрипторы n, ваш поток будет добавлен в n очереди ожидания. Когда с дескриптором происходит что-то, что может быть опрошено (например, данные поступают в сокет), все потоки в этой очереди ожидания просыпаются.

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

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

В целом, я думаю, это стирка.

Если вы собираетесь работать с большим количеством дескрипторов, вам лучше использовать более масштабируемый (хотя и непереносимый) механизм, такой как epoll. При epoll несколько потоков, каждый из которых обрабатывает пул дескрипторов, должны очень хорошо масштабироваться.

Answer 2

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