O>>Асинхронность состоит в том, что пользовательский поток вовсе не обязан все время ждать сообщения. Он может заниматься чем-то другим и периодияеки обрабатывать что там ему наприходило.
_>Вообще то GetQueuedCompletionStatus вполне себе ждёт сообщения, если их нет в очереди. )))

if dwMilliseconds is INFINITE, the function will never time out. If dwMilliseconds is zero and there is no I/O operation to dequeue, the function will time out immediately.

(c)

O>>Асинхронность состоит в том, что пользовательский поток вовсе не обязан все время ждать сообщения. Он может заниматься чем-то другим и периодияеки обрабатывать что там ему наприходило.
_>Вообще то GetQueuedCompletionStatus вполне себе ждёт сообщения, если их нет в очереди. )))

if dwMilliseconds is INFINITE, the function will never time out. If dwMilliseconds is zero and there is no I/O operation to dequeue, the function will time out immediately.

(c)
Но конечно же так делать далеко не всегда оптимальная стратегия. Но вполне реальная. К примеру имеем видеокодер реального времени (с видеокамеры) с внутренним буфером который он иногда сбрасывает на диск. Типа накодировал себе 16 мегабайт — проверил что предыдущая запись завершилась, и если да — запустил асинхронный сброс текущего буфера, а если нет — ну значит отращиваем буфер для следующей порции видео, видеокамера то ждать не будет.
Но обычно эффективнее таки ждать вечно когда делать больше нечего. Имеем распаковщик архивов — он запускает асинхронное чтение, и запустив — занимается декодированной порции данных прочитанных операцией стартованной в предыдущей итерации. Как декодировали — ждем довычитки порции данных, запускаем новую операцию на будущее и декодируем нововычитанные данные.
Но на самом деле самое интересное что можно запустить 100500 IO операций. В случае чтения с различных мест (разных файлов, разных мест однго и того же файла) это позволяет IO manager'у оптимальным образом группировать запросы в NCQ. Если кончено он умеет