Почему многие считают порт завершения ввода-вывода быстрой и удобной моделью?
Каковы преимущества и недостатки порта завершения ввода-вывода?
Я хочу знать некоторые моменты, которые делают IOCP быстрее, чем другие модели.
Если вы можете объяснить это, сравнивая другие модели (выберите, epoll, традиционный многопоток/процесс), было бы лучше.
Порты завершения ввода-вывода потрясающие. Нет лучшего слова, чтобы описать их. Если что-то в Windows было сделано правильно, так это завершение портов.
Вы можете создать некоторое количество потоков (на самом деле не имеет значения, сколько их) и заставить их все блокироваться на одном порту завершения до наступления события (либо того, которое вы публикуете вручную, либо события из таймер или асинхронный ввод-вывод или что-то еще). Затем порт завершения разбудит один поток для обработки события до указанного вами предела. Если вы ничего не указали, предполагается, что «до числа ядер ЦП», что действительно приятно.
Если активных потоков уже больше максимального предела, он будет ждать, пока один из них не будет выполнен, а затем передать событие потоку, как только он перейдет в состояние ожидания. Кроме того, он всегда будет пробуждать потоки в порядке LIFO, поэтому велика вероятность, что кэши еще не остыли.
Другими словами, порты завершения — это беспроблемный «опрос событий», а также решение «загружать ЦП настолько, насколько это возможно».
Вы можете запускать чтение и запись файлов в порт завершения, сокеты или что-то еще, что можно ожидать. И вы можете публиковать свои собственные события, если хотите. Каждое пользовательское событие имеет по крайней мере одно целое число и один указатель данных (если вы используете структуру по умолчанию), но на самом деле вы не ограничены этим, поскольку система с радостью примет и любую другую структуру.
Кроме того, порты завершения работают быстро, очень быстро. Когда-то мне нужно было уведомить один поток от другого. Так случилось, что у этого потока уже был порт завершения для файлового ввода-вывода, но он не перекачивал сообщения. Итак, я задумался, не следует ли мне просто стиснуть зубы и использовать порт завершения для простоты, даже несмотря на то, что публикация сообщения в потоке, очевидно, была бы намного эффективнее. Я был в нерешительности, поэтому я сравнил. На удивление оказалось, что порты завершения были примерно в 3 раза быстрее. Итак... быстрее и гибче, решение было несложным.
ReleaseSemaphore, а главный поток, который ставит в очередь операции чтения, ждет семафора с WaitForSingleObject. Это ограничивает количество чтений в полете до всего, что я хочу.
- person user541686; 01.08.2014
bool каждый раз, когда ожидание возвращается.
- person Damon; 02.08.2014
используя IOCP, мы можем решить проблему «один поток на клиента». Общеизвестно, что производительность сильно снижается, если программное обеспечение не работает на настоящей многопроцессорной машине. Потоки — это системные ресурсы, которые не являются ни неограниченными, ни дешевыми.
IOCP позволяет нескольким потокам (рабочим операциям ввода/вывода) обрабатывать ввод/вывод нескольких клиентов «справедливо». Потоки приостанавливаются и не используют циклы ЦП, пока не будет чем заняться.
Также вы можете прочитать некоторую информацию в этой замечательной книге https://rads.stackoverflow.com/amzn/click/com/0321256190
OVERLAPPED Ввод-вывод очень хорошо преодолевает один поток на клиента, спасибо. Что IOCP приносит в таблицу, так это (как вы правильно упомянули) распределение нагрузки между несколькими потоками. Для большинства приложений использование OVERLAPPED I/O из одного потока проще и эффективнее. Только серверы приложений большого объема должны учитывать IOCP.
- person Ben Voigt; 12.03.2011
MsgWaitForMultipleObjectsEx и процедуры завершения. Тот же стиль программирования конечного автомата, что и IOCP, и нет необходимости в синхронизации потоков.
- person Ben Voigt; 12.03.2011
Порты завершения ввода-вывода предоставляются операционной системой как асинхронная операция ввода-вывода, что означает, что она выполняется в фоновом режиме (обычно аппаратно). Система не тратит ресурсы (например, потоки) в ожидании завершения ввода-вывода. Когда ввод-вывод завершен, аппаратное обеспечение отправляет прерывание в ОС, которая затем пробуждает соответствующий процесс/поток для обработки результата. НЕПРАВИЛЬНО: IOCP НЕ требует аппаратной поддержки (см. комментарии ниже)
Обычно один поток может ожидать большое количество завершений ввода-вывода, занимая при этом очень мало ресурсов, когда ввод-вывод не вернулся.
Другие асинхронные модели, которые не основаны на портах завершения ввода-вывода, обычно используют пул потоков и имеют потоки, ожидающие завершения ввода-вывода, тем самым используя больше системных ресурсов.
Обратной стороной является то, что порты завершения ввода-вывода обычно требуют аппаратной поддержки, и поэтому они обычно не применимы ко всем асинхронным сценариям.
