каналы действительно ли posix легки?
В приложении Linux я использую каналы для передачи информации между потоками.
Идея позади использования каналов состоит в том, что я могу ожидать нескольких каналов сразу с помощью опроса (2). Это работает хорошо на практике, и мои потоки спят большую часть времени. Они только просыпаются, если существует что-то, чтобы сделать.
В пространстве пользователя взгляд каналов точно так же, как два дескрипторов файлов. Теперь интересно, сколько ресурсов такие каналы используют на стороне ОС.
Btw: В моем приложении я только отправляю единственные байты время от времени. Думайте о моих каналах как простые очереди сообщений, которые позволяют мне потокам получения пробуждения, говорят им отправлять некоторые данные состояния или завершаться.
2 ответа
Измерьте, и вы узнаете. Полные процессы с трубами достаточно легкие для множества приложений. Другим приложениям требуется что-то более легкое, например потоки ОС (pthreads - популярный выбор для многих приложений Unix), или сверхлегкое, например пакет потоков пользовательского уровня, который никогда не переходит в режим ядра, кроме как для обработки ввода-вывода. Хотя единственный способ узнать наверняка - это измерить, каналы, вероятно, достаточно хороши для нескольких десятков потоков, тогда как вам, вероятно, понадобятся потоки на уровне пользователя, когда вы дойдете до нескольких десятков тысяч потоков. Я не знаю, где именно должны быть проведены границы с использованием сегодняшних кодов. Если бы я хотел знать, я бы измерил: -)
Нет, я бы не считал трубы "легковесными", но это не обязательно означает, что они не подходят для вашего приложения.
Отправка байта по трубе потребует минимум 3 системных вызова (запись, опрос, чтение). Использование очереди в памяти и операций pthread (mutex_lock, cond_signal) требует гораздо меньших накладных расходов. Дескрипторы открытых файлов определенно потребляют ресурсы ядра; именно поэтому по умолчанию процессы обычно ограничены 256 открытыми файлами (не то чтобы этот лимит не мог быть расширен в случае необходимости).
Тем не менее, решение pipe/poll для межпоточной коммуникации также имеет свои преимущества: особенно если вам нужно ожидать ввода из комбинации источников (сеть + другие потоки).