Использование select() then read() против цикла blocking read()

Question

Я работаю над многопоточным кодом сервера, где я создаю 2 потока, которые взаимодействуют с блокирующим TCP Socket после accept().

Тема № 1 проверяет, есть ли команды из очереди сообщений и записывается в сокет. Тема № 2 - это простой цикл while, который вызывает read, а затем блокирует, если нет готовых к чтению данных.

Однако мой коллега сказал мне, что я не должен делать то время цикла с read, как он будет тратить циклы CPU (Это блокирует read, не ядро ​​положить нить спать?), Что я должен использовать select() системы затем запустите сокет.

Я ошибаюсь, считая прочитанную нить? Какой подход лучше?

Answer 1

Вы правы, что поток не потребляет процессор во время блокировки на I/O.

Syscall является жизнеспособной альтернативой, но его основным вариантом использования является мультиплексирование ввода/вывода из/в несколько каналов. В этом случае небезопасно для одного потока обслуживать все каналы путем блокировки чтения (или записи), поскольку он часто блокируется в ожидании данных с одного канала, в то время как другой имеет данные, готовые и ожидающие. С другой стороны, вы не хотите выполнять неблокирующий читает в цикле, так как будет отходов CPU.

Что касается того, чтобы предпочесть блокировки на read() или блокированием select() (или poll()) для управления одним каналом, это немного из сравнения яблок к апельсинам, но если таковые есть выбор, то это более простой в блок на read(). Это то, что я сделал бы. Сравнение яблок и яблок будет больше по линиям нескольких потоков или дочерних процессов, каждый из которых блокирует read(), используя другой канал, против одного потока одного процесса, управляющего несколькими каналами, с помощью select().

Answer 2

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

Вместо этого Чтение должно вестись по событию. Это означает, что поток Read не будет запущен вообще, пока не будут доступны данные для чтения. Итак, что ваш друг предложил правильно. Вы должны перейти к модели, управляемой событиями. То, что вызвал так называемый вызов Select(), указывает, что стек TCP информирует прочитанный поток, когда есть данные.

поэтому вместо того, чтобы ваш поток проверял, доступны ли данные непрерывно, TCP сообщит вам, когда будут данные для вас.

Надежда его ясно