Почему многие люди говорят, что порт завершения ввода/вывода - это быстрая и приятная модель?
Каковы преимущества и недостатки порта завершения ввода-вывода?
Я хочу знать некоторые моменты, которые ускоряют IOCP, чем другие модели.
Если вы можете объяснить это, сравнивая другие модели (select, epoll, традиционный многопоточный поток/процесс), было бы лучше.
Порт завершения ввода/вывода является удивительным. Нет лучшего слова, чтобы описать их. Если что-либо в Windows было сделано правильно, это завершение портов.
Вы можете создать некоторое количество потоков (на самом деле не важно, сколько) и сделать их все блокированными на одном порт завершения до события (либо одного из них, отправленного вручную, либо события из таймер или асинхронный ввод-вывод или что-то еще). Затем порт завершения пробуждает один поток для обработки события, до указанного вами предела. Если вы ничего не указали, это будет предполагать "до количества ядер процессора", что очень приятно.
Если количество потоков больше, чем максимальное ограничение, будет ждать, пока одно из них не будет выполнено, а затем передайте событие в поток, как только оно перейдет в состояние ожидания. Кроме того, он всегда будет запускать потоки в порядке LIFO, поэтому есть вероятность, что кеши еще теплые.
Другими словами, порты завершения - это "опрос бездействия" для событий, а также решение "заполнить процессор как можно больше".
Вы можете загружать файлы и записывать их в порт завершения, сокеты или что-то еще, что необходимо. И вы можете публиковать свои собственные события, если хотите. Каждое пользовательское событие имеет по крайней мере одно целое число и один указатель на ценность данных (если вы используете структуру по умолчанию), но на самом деле вы не ограничены этим, так как система с радостью примет любую другую структуру.
Кроме того, порты завершения быстро, действительно очень быстро. Когда-то мне нужно было известить один поток от другого. В этом потоке уже был порт завершения для ввода-вывода файлов, но он не перекачивал сообщения. Итак, я задавался вопросом, нужно ли мне просто укусить пулю и использовать порт завершения для простоты, хотя публикация сообщения о потоке, очевидно, будет намного более эффективной. Я не определился, поэтому я сравнил результаты. Сюрприз, оказалось, что порты завершения были примерно в 3 раза быстрее. Итак... быстрее и гибче, решение было не сложно.
используя IOCP, мы можем преодолеть проблему "один поток на клиент". Общеизвестно, что производительность сильно падает, если программное обеспечение не работает на истинной многопроцессорной машине. Темы - это системные ресурсы, которые не являются ни неограниченными, ни дешевыми.
IOCP предоставляет способ иметь несколько потоков (операций ввода-вывода) для обработки ввода/вывода нескольких клиентов "справедливо". Потоки приостановлены и не используют циклы процессора, пока не будет что-то делать.
Также вы можете прочитать некоторую информацию в этой приятной книге http://www.amazon.com/Windows-System-Programming-Johnson-Hart/dp/0321256190
По моему опыту недостатком порта завершения ввода-вывода может быть синий экран смерти с некоторыми последовательными адаптерами RS-232 из-за ошибок в драйверах.
Порт завершения ввода/вывода предоставляется O/S как операция асинхронного ввода-вывода, что означает, что он встречается в фоновом режиме (обычно в аппаратном обеспечении). Система не тратит никаких ресурсов (например, потоков), ожидающих завершения ввода-вывода. Когда ввод-вывод завершен, оборудование отправляет прерывание на O/S, которое затем пробуждает соответствующий процесс/поток для обработки результата. НЕПРАВИЛЬНО: IOCP НЕ требует поддержки аппаратного обеспечения (см. комментарии ниже)
Как правило, один поток может ждать большого количества завершений ввода-вывода, в то же время занимая очень мало ресурсов, когда I/O не вернулся.
Другие асинхронные модели, которые не основаны на портах завершения ввода-вывода, обычно используют пул потоков и потоки ожидают завершения ввода-вывода, тем самым используя больше системных ресурсов.
Откидной стороной является то, что порты завершения ввода-вывода обычно требуют поддержки аппаратного обеспечения, и поэтому они обычно не применимы ко всем сценариям асинхронного программирования.