Синхронный и асинхронный ввод вывод кратко

Обновлено: 04.07.2024

Преимущество описанного модульного подхода к аппаратуре в том, что центральный процессор , память и внешние устройства могут функционировать параллельно. Работой каждого устройства управляет специальный контроллер . При необходимости выполнения ввода-вывода центральный процессор генерирует прерывание , в результате которого вызывается операционная система , в свою очередь , в качестве реакции на прерывание запускающая драйвер устройства , соответственно, активизирующий его контроллер . Каждый контроллер устройства имеет локальный буфер – специализированную память для обмена информацией между компьютером и устройством. Для того, чтобы контроллер мог начать вывод на устройство, предварительно центральный процессор (точнее, драйвер устройства , запущенный на нем) должен переслать информацию из заданной области оперативной памяти в буфер устройства. Далее контроллер устройства уже выполняет вывод информации из буфера на само устройство (например, записывает ее в заданную область жесткого диска). По окончании обмена информацией, контроллер генерирует сигнал о прерывании ( interrupt ) по системной шине, этим информируя процессор об окончании операции . Для того, чтобы избежать повторных пересылок больших объемов информации, в современных компьютерах применяют DMA ( Direct Memory Access ) – контроллеры – контроллеры с прямым доступом к оперативной памяти. Такие контроллеры используют при обмене с устройством не свою специализированную память , а напрямую область оперативной памяти, в которой и размещается буфер обмена.

Обработка прерываний

Операционную систему можно рассматривать как программу , управляемую прерываниями ( interrupt - driven program ). Прерывание центрального процессора передает управление подпрограмме обработки данного вида прерываний, являющейся частью ОС. В большинстве компьютеров этот механизм реализован через вектор прерываний ( interrupt vector ) – резидентный массив в оперативной памяти, в котором хранятся доступные по номерам прерываний адреса подпрограмм-обработчиков прерываний (модулей ОС). При обработке прерывания аппаратура и ОС сохраняют адрес прерванной команды .При возобновлении вычислений будет вновь повторено выполнение прерванной команды.

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

Кроме прерываний, генерируемых аппаратурой неявно при вычислениях (например, отсутствие страницы в оперативной памяти), возможно также программируемое прерывание (trap ; дословно – ловушка ) с помощью специальной команды процессора, - например, при обнаруженной ошибке в программе. В случае такого прерывания также работает общий механизм запуска обработчика прерывания – части ОС. Таким образом, с упрощенной точки зрения, ОС можно рассматривать как набор обработчиков прерываний.

При прерывании ОС сохраняет состояние процессора – значения регистров и значение счетчика команд (program counter – PC) – адреса прерванной команды .Обработчик прерывания в ОС определяет по содержимому сегмента объектного кода, какого вида прерывание возникло и какие действия по его обработке следует предпринять. Среди возможных видов прерываний, кроме фиксации различных ошибок, имеются также прерывания по таймеру – периодические прерывания через определенный квант времени, предназначенные для опроса устройств (polling) – действий операционной системы по периодической проверке состояния всех портов и внешних устройств , которое может меняться с течением времени: например, к USB -порту была подключена флэшка; принтер закончил печать и освободился, и т.д. ОС выполняет реконфигурацию системы и корректирует системные таблицы, хранящие информацию об устройствах.

Архитектура ввода-вывода

На рис. 4.2 изображена временная диаграмма прерываний процессора, выполняющего ввод- вывод .

Временная диаграмма прерываний процессора при вводе-выводе.

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

Имеются две разновидности режима ввода -вывода – синхронный и асинхронный.

Синхронный ввод- вывод – это ввод- вывод , выполнение которого приводит к переходу программы в состояние ожидания, до тех пор, пока операция ввода-вывода не будет полностью завершена. На аппаратном уровне – команда ввода-вывода переводит процессор в состояние ожидания ( idle ) до следующего прерывания. При данном режиме в каждый момент выполняется не более одного запроса на ввод- вывод ; одновременный ввод- вывод отсутствует. Синхронный вывод выполняют всем программистам привычные операторы вида println(x).При их использовании в программах мы не задумываемся над тем, что используем достаточно неэффективный вариант синхронного ввода-вывода. Однако до сих пор мышление большинства программистов – последовательное, в том смысле, что о своей программе они мыслят как о чисто последовательно выполняемой, и вообще не думают о возможности какого-либо распараллеливания. При отладке программы, либо если размер выводимой информации невелик, это обычно вполне допустимо.

Асинхронный ввод-вывод – ввод- вывод , выполняемый параллельно с выполнением основной программы . После того. как начинается асинхронный ввод-вывод , управление возвращается пользовательской программе, без ожидания завершения ввода-вывода (последнее может быть выполнено специальной явной операцией). Таким образом, операция асинхронного обмена как бы разбивается на две: начать ввод-вывод и закончить ввод-вывод. Последняя выполняется для того, чтобы в этом месте программа все же ожидала завершения обмена, когда его результат необходим для дальнейших вычислений. Такой подход к реализации обмена более труден для понимания программистами и может привести к ошибкам (например, использована только операция начала ввода-вывода, а вызов операции его окончания забыт).

Таблица состояния устройств

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

Архитектура синхронного (a) и асинхронного (b) ввода-вывода иллюстрируется на рис. 4.3.

Существует два типа синхронизации ввода-вывода: синхронный ввод-вывод и асинхронный ввод-вывод. Асинхронный ввод-вывод также называется перекрытой операцией ввода-вывода.

В синхронных файловых операциях ввода-вывода поток запускает операцию ввода-вывода и сразу переходит в состояние ожидания до тех пор, пока запрос ввода-вывода не будет завершен. Поток, выполняющий Асинхронный файловый ввод-вывод , отправляет в ядро запрос ввода-вывода, вызывая соответствующую функцию. Если запрос принимается ядром, вызывающий поток продолжит обработку другого задания, пока ядро не выведет сигнал о завершении операции ввода-вывода. Затем он прерывает свое текущее задание и обрабатывает данные из операции ввода-вывода по мере необходимости.

На следующем рисунке показаны два типа синхронизации.

синхронный и асинхронный ввод-вывод

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

Синхронные и асинхронные вопросы ввода-вывода

Если файл или устройство открыто для синхронного ввода-вывода (то есть не задано _ _ Перекрытие флага файла ), последующие вызовы функций, таких как WriteFile , могут блокировать выполнение вызывающего потока до тех пор, пока не произойдет одно из следующих событий:

  • Операция ввода-вывода завершается (в этом примере — запись данных).
  • Ошибка ввода-вывода. (Например, канал закрывается с другого конца.)
  • В самом вызове произошла ошибка (например, один или несколько параметров недопустимы).
  • Другой поток в процессе вызывает функцию канцелсинчронаусио с помощью обработчика потока заблокированного потока, который прерывает операции ввода-вывода для этого потока и завершает операцию ввода-вывода.
  • Заблокированный поток завершается системой; Например, сам процесс завершается, или другой поток вызывает функцию TerminateThread с помощью обработчика заблокированного потока. (Обычно это рассматривается как Последнее средство, а не хорошая разработка приложений.)

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

Процесс открывает файл для асинхронного ввода-вывода при вызове функции CreateFile путем указания флага File _ Flag _ OVERLAPPED в параметре двфлагсандаттрибутес . Если _ _ Перекрытие флага файла не задано, файл открывается для синхронного ввода-вывода. Когда файл был открыт для асинхронного ввода-вывода, указатель на структуру OVERLAPPED передается в вызов ReadFile и WriteFile. При выполнении синхронного ввода-вывода эта структура не требуется в вызовах функций ReadFile и WriteFile.

Хотя CreateFile — это наиболее распространенная функция, используемая для открытия файлов, томов диска, анонимных каналов и других аналогичных устройств, операции ввода-вывода также можно выполнять с помощью приведением к другим системным объектам, таким как сокет, созданный сокетом или функцией Accept .

Дескрипторы объектов каталога получаются путем вызова функции CreateFile с помощью атрибута File _ Flag _ BACKUP _ семантика . Дескрипторы каталогов практически никогда не используются — приложения резервного копирования являются одним из нескольких приложений, которые обычно их используют.

После открытия объекта File для асинхронного ввода-вывода ПЕРЕкрывающаяся структура должна быть правильно создана, инициализирована и передана в каждый вызов таких функций, как ReadFile и WriteFile. При использовании ПЕРЕкрывающейся структуры в асинхронных операциях чтения и записи учитывайте следующее.

  • Не выделяйте или не изменяйте перекрывающиеся структуры или буфер данных до тех пор, пока не будут завершены все асинхронные операции ввода-вывода в объект File.
  • Если вы объявили указатель на структуру OVERLAPPED как локальную переменную, не выработайте локальную функцию до тех пор, пока не завершится выполнение всех асинхронных операций ввода-вывода в файловый объект. Если локальная функция завершается преждевременно, ПЕРЕкрывающаяся структура выходит из области, и она будет недоступна для любых функций ReadFile или WriteFile , которые он обнаруживает вне этой функции.

Можно также создать событие и разместить его в структуре OVERLAPPED ; функции ожидания можно затем использовать для ожидания завершения операции ввода-вывода, ожидая обработчик события.

Как отмечалось ранее, при работе с асинхронным маркером приложения должны соблюдать осторожность при определении того, когда следует освобождать ресурсы, связанные с заданной операцией ввода-вывода для этого маркера. Если маркер освобожден преждевременно, ReadFile или WriteFile может неправильно сообщить о том, что операция ввода-вывода завершена. Кроме того, функция WriteFile иногда возвращает true со значением GetLastError , равной Success Error, несмотря на то, что использует асинхронный обработчик (который также может _ возвращать значение false с _ _ ожидающими операциями ввода-вывода с ошибками). Программисты, привыкшие к синхронному проектированию операций ввода-вывода, обычно освобождают ресурсы буфера данных на этом этапе, так как значение true и Ошибка _ означают, что операция завершена. Однако, если порты завершения ввода-вывода используются с этим асинхронным маркером, пакет завершения также будет отправлен, даже если операция ввода-вывода завершается немедленно. Иными словами, если приложение освобождает ресурсы после того, как функция WriteFile возвращает значение true , а в подпрограммы порта завершения ввода-вывода возникнет ошибка, то в нем будет выводится ошибка двойной свободной ситуации. _ В этом примере рекомендуется разрешить подпрограммы порта завершения, чтобы она отвечала исключительно за все операции освобождения таких ресурсов.

Система не поддерживает указатель файла на асинхронных дескрипторах для файлов и устройств, поддерживающих указатели на файлы (то есть поиск устройств), поэтому позиция файла должна быть передана в функции чтения и записи в соответствующих элементах данных смещения в структуре OVERLAPPED . Дополнительные сведения см. в разделе WriteFile и ReadFile.

Расположение указателя файла для синхронного маркера поддерживается системой по мере чтения или записью данных, а также может быть обновлено с помощью функции SetFilePointer или сетфилепоинтерекс .

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

Чтобы отменить все ожидающие асинхронные операции ввода-вывода, используйте один из следующих способов.

    — эта функция отменяет только операции, выданные вызывающим потоком для указанного маркера файла. — эта функция отменяет все операции, выданные потоками для указанного маркера файла.

Используйте канцелсинчронаусио для отмены ожидающих синхронных операций ввода-вывода.

Функции реадфиликс и вритефиликс позволяют приложению указать подпрограммы для выполнения (см. филеиокомплетионраутине) по завершении асинхронного запроса ввода-вывода.

Синхронная диаграмма

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

Обычно в процессорных и измерительных системах направление потока данных (на ввод или на вывод) считают относительно компьютера (процессора), стоящего в центре рассматриваемой архитектуры. В частности, отсчёты АЦП и цифровых (дискретных) входов считают данными на ввод, а отсчёты ЦАП и цифровых (управляющих) выходов – данными на вывод.

При асинхронным вводе и выводе не сохраняются интервалы времени (периодичность) передачи отсчётов на ввод или на вывод. При этом, данные поступают на ввод или вывод в темпе самого интерфейса передачи данных, с непредсказуемыми задержками буферизации, без сохранения каких-либо временны̀х интервалов. В частности, это означает для программиста, что при использовании асинхронных функций ввода-вывода бессмысленно сопоставлять моменты вызова функции асинхронного ввода-вывода с физическими моментами выполнения данной операции “по ту сторону интерфейса” (подобное сопоставление имеет смысл только лишь при статистическом методе обработки данных). Факт выполнения асинхронной операции на вывод может быть проверен с помощью подтверждения (если данная операция на вывод имеет подтверждение, или подтверждение можно получить последующей операцией ввода данных). При асинхронном вводе-выводе упомянутая выше буферизация данных может сыграть противоположную роль и увеличить неопределённость времени доставки данных при отсутствии механизма синхронизации и управления трафиком передачи данных.

При синхронном сборе в системах сбора данных нередко программная среда на приёмной стороне получает данные асинхронно, но, если известно, что полученные данные были собраны без потерь и синхронно (например, АЦП в синхронном режиме), то программно эти данные рассматриваются как синхронные, например, при использовании спектральных алгоритмах ЦОС. Аналогично, при реализациях синхронного вывода через буфер передающая сторона асинхронно заполняет буфер (с контролем его заполнения), а приёмная сторона (например, ЦАП) интерпретирует полученные данные как синхронные.

Когда несинхронность ввода-вывода может составлять типично малую часть от заданного периода сбора данных, то употребляют термин квазисинхронный режим ввода-вывода. В таком режиме соблюдается установленный средний период сбора данных на фоне возможной фазовой нестабильности периодического процесса ввода-вывода. Квазисинхронный режим, как правило, вполне приемлем для систем управления, но на ввод квазисинхронный режим сбора (например, АЦП) может быть применён там, где не применяется спектральная обработка сигнала. Квазисинхрнный режим не позволяет восстановить исходную форму сигнала, поскольку отсчёты данных не жёстко привязаны ко времени, за исключением случая, когда случайная величина фазовой нестабильности количественно известна и этот фактор учитывается при восстановлении формы сигнала.

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

Перейти к другим терминам Cтатья создана:14.10.2015
О разделе "Терминология" Последняя редакция:17.08.2019

Синхронный и асинхронный ввод-вывод используется в различных системах сбора данных (LTR, E-502, L-502, E20-10, E14-x40 и т.д.) и эти термины активно употребляются в эксплуатационной документации этих изделий.

Существует два типа синхронизации ввода-вывода: синхронный ввод-вывод и асинхронный ввод-вывод. Асинхронный ввод-вывод также называется перекрывающимся вводом-выводом.

При синхронном файловом вводе-выводе поток запускает операцию ввода-вывода и немедленно переходит в состояние ожидания до завершения запроса ввода-вывода. Поток, выполняющий асинхронный файловый ввод-вывод, отправляет запрос ввода-вывода ядру, вызывая соответствующую функцию. Если запрос принят ядром, вызывающий поток продолжает обработку другого задания до тех пор, пока ядро не подаст потоку сигнал о завершении операции ввода-вывода. Затем он прерывает свою текущую работу и обрабатывает данные из операции ввода-вывода по мере необходимости.

Эти два типа синхронизации показаны на следующем рисунке.

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

Соображения по поводу синхронного и асинхронного ввода-вывода

Если файл или устройство открыты для синхронного ввода-вывода (то есть FILE_FLAG_OVERLAPPED не указан), последующие вызовы функций, таких как WriteFile, могут блокировать выполнение вызывающего потока до тех пор, пока не произойдет одно из следующих событий:

  • Операция ввода-вывода завершается (в данном примере это запись данных).
  • Возникает ошибка ввода-вывода. (Например, другой конец закрыт)
  • В самом вызове была допущена ошибка (например, один или несколько параметров недопустимы).
  • Другой поток в процессе вызывает функцию CancelSynchronousIo, используя дескриптор потока заблокированного потока, который завершает ввод-вывод для этого потока, не выполнив операцию ввода-вывода.
  • Заблокированный поток завершается системой; например, завершается сам процесс или другой поток вызывает функцию TerminateThread, используя дескриптор заблокированного потока. (Это обычно считается последним средством и не очень хорошим дизайном приложения.)

Процесс открывает файл для асинхронного ввода-вывода при вызове CreateFile, указав флаг FILE_FLAG_OVERLAPPED в параметре dwFlagsAndAttributes. Если FILE_FLAG_OVERLAPPED не указан, файл открывается для синхронного ввода-вывода. Когда файл открыт для асинхронного ввода-вывода, указатель на перекрывающуюся структуру передается в вызов ReadFile и WriteFile. При выполнении синхронного ввода-вывода эта структура не требуется в вызовах ReadFile и WriteFile.

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

Хотя CreateFile является наиболее распространенной функцией, используемой для открытия файлов, дисковых томов, анонимных каналов и других подобных устройств, операции ввода-вывода также могут выполняться с использованием типа дескриптора из других системных объектов, таких как сокет, созданный функциями socket или accept.

Дескрипторы объектов каталога получаются путем вызова функции CreateFile с атрибутом FILE_FLAG_BACKUP_SEMANTICS. Дескрипторы каталогов почти никогда не используются—приложения резервного копирования являются одним из немногих приложений, которые обычно используют их.

После открытия объекта file для асинхронного ввода-вывода перекрывающаяся структура должна быть правильно создана, инициализирована и передана в каждый вызов таких функций, как ReadFile и WriteFile. При использовании ПЕРЕКРЫВАЮЩЕЙСЯ структуры в асинхронных операциях чтения и записи имейте в виду следующее:

  • Не освобождайте и не изменяйте перекрывающуюся структуру или буфер данных до тех пор, пока не будут завершены все асинхронные операции ввода-вывода с файловым объектом.
  • Если вы объявите указатель на перекрывающуюся структуру как локальную переменную, не выходите из локальной функции до тех пор, пока не будут завершены все асинхронные операции ввода-вывода с файловым объектом. Если локальная функция будет выведена преждевременно, перекрывающаяся структура выйдет за пределы области видимости и будет недоступна для любых функций ReadFile или WriteFile, с которыми она сталкивается за пределами этой функции.

Как уже говорилось ранее, при работе с асинхронным дескриптором приложения должны проявлять осторожность при определении времени освобождения ресурсов, связанных с указанной операцией ввода-вывода на этом дескрипторе. Если дескриптор освобожден преждевременно, ReadFile или WriteFile могут неправильно сообщить о завершении операции ввода-вывода. Кроме того, функция WriteFile иногда возвращает TRUE со значением GetLastError ERROR_SUCCESS, даже если она использует асинхронный дескриптор (который также может возвращать FALSE с ERROR_IO_PENDING).

Программисты, привыкшие к синхронному проектированию ввода-вывода, обычно освобождают ресурсы буфера данных в этот момент, потому что TRUE и ERROR_SUCCESS означают, что операция завершена. Однако, если порты завершения ввода-вывода используются с этим асинхронным дескриптором, пакет завершения также будет отправлен, даже если операция ввода-вывода завершится немедленно. Другими словами, если приложение освобождает ресурсы после того, как WriteFile возвращает TRUE с ERROR_SUCCESS в дополнение к процедуре завершения порта ввода-вывода, оно будет иметь условие двойной свободной ошибки. В этом примере рекомендация будет заключаться в том, чтобы позволить процедуре порта завершения нести исключительную ответственность за все операции по освобождению таких ресурсов.

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

Положение указателя файла для синхронного дескриптора поддерживается системой по мере чтения или записи данных, а также может быть обновлено с помощью функции SetFilePointer или SetFilePointerEx.

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

Поэтому, если приложение запускает две операции ввода-вывода и ожидает дескриптор файла, нет никакого способа определить, какая операция завершена, когда дескриптор установлен в сигнальное состояние. Если приложение должно выполнить несколько асинхронных операций ввода-вывода в одном файле, оно должно ожидать дескриптора события в определенной ПЕРЕКРЫВАЮЩЕЙСЯ структуре для каждой операции ввода-вывода, а не общего дескриптора файла.

Чтобы отменить все отложенные асинхронные операции ввода-вывода, используйте либо:

  • CancelIo—эта функция отменяет только операции, выполняемые вызывающим потоком для указанного дескриптора файла.
  • CancelIoEx—эта функция отменяет все операции, выполняемые потоками для указанного дескриптора файла.

Функции ReadFileEx и WriteFileEx позволяют приложению указать процедуру для выполнения (FileIOCompletionRoutine) после завершения асинхронного запроса ввода-вывода.

Читайте также: