Здравствуйте, alex_public, Вы писали:

_>IOCP поток естественно не будет ничего ждать. А вот "обработка данных, пришедших по сети" будет произведена только после ожиданий (причём в такой модели двойных).

_>Понимаешь, на самом деле все эти ждущие потоки (что в синхронном варианте, что в асинхронном) — это абсолютно не страшная вещь. И я акцентировал внимание на их наличие в асинхронном коде только по той причине, что некоторые дурачки утверждали в своих статьях, что их нет и что как раз по этому асинхронный код намного лучше. Нет, они как раз есть. Но в этом ничего страшного с точки зрения эффективности нет. А вот что реально "страшно" с точки зрения эффективности работы программы, так это суммарная задержка от момента попадания пакета в сетевую карту, до момента его обработки в прикладном коде. Потому как рассуждать о количестве выдерживаемых в минуту запросов без уточнения величины латентности могут только очень сомнительные специалисты.

Good point, правильнее было бы написать "нет еще одного дополнительного ждущего потока специально под данную асинхронную операцию" (хотя иногда .Net может и запустить еще один IO поток, если запросов слишком много).
Самое интересное возникает в пиковых нагрузках, когда к моменту выполнения продолжения очередной завершенной IO операции в очереди IO потока уже есть следующая. В этом случае IO поток вообще не будет засыпать и лишних переключений контекста не будет, все потоки (потоки IO и потоки worker thread pool) будут полностью использовать выделенные им кванты времени.

По поводу двойных ожиданий. Вот тут пишут, что HttpClient умеет выполнять продолжения сам, без перекидывания их в worker thread.

Здравствуйте, alex_public, Вы писали:

_>IOCP поток естественно не будет ничего ждать. А вот "обработка данных, пришедших по сети" будет произведена только после ожиданий (причём в такой модели двойных).

_>Понимаешь, на самом деле все эти ждущие потоки (что в синхронном варианте, что в асинхронном) — это абсолютно не страшная вещь. И я акцентировал внимание на их наличие в асинхронном коде только по той причине, что некоторые дурачки утверждали в своих статьях, что их нет и что как раз по этому асинхронный код намного лучше. Нет, они как раз есть. Но в этом ничего страшного с точки зрения эффективности нет. А вот что реально "страшно" с точки зрения эффективности работы программы, так это суммарная задержка от момента попадания пакета в сетевую карту, до момента его обработки в прикладном коде. Потому как рассуждать о количестве выдерживаемых в минуту запросов без уточнения величины латентности могут только очень сомнительные специалисты.

Good point, правильнее было бы написать "нет еще одного дополнительного ждущего потока специально под данную асинхронную операцию" (хотя иногда .Net может и запустить еще один IO поток, если запросов слишком много).
Самое интересное возникает в пиковых нагрузках, когда к моменту выполнения продолжения очередной завершенной IO операции в очереди IO потока уже есть следующая. В этом случае IO поток вообще не будет засыпать и лишних переключений контекста не будет, все потоки (потоки IO и потоки worker thread pool) будут полностью использовать выделенные им кванты времени.

По поводу двойных ожиданий. Вот тут пишут, что HttpClient умеет выполнять продолжения в IOCP потоке, без перекидывания их в worker thread.