где/как я могу определить, использует ли класс .net IOCP?

Question

Update

Я задал неправильный вопрос, перефразировали (на основе большой информации о ответах и ​​комментариях):

Есть ли хороший источник по операциям асинхронной .net бытия реального асинхронные, таким образом, либо IOCP или async (перекрывается)? Есть ли какой-нибудь быстрый способ узнать, работают ли несколько классов?

Example of not trusting framework developers blindly

естественная отправная точка для создания FileStream является статическим методом File.Open(), документация, для которой ничего не упоминает о синхронности FileStream, который создается! Также вы не можете предоставить FileOptions (которые используются для указания волшебного флажка FileOptions.Asynchronous).

Вместо этого FileStream создается с помощью FileOptions.None. Любые асинхронные операции легко подделываются обязательной реализацией базового класса Stream, который просто переносит соответствующий синхронный метод в делегат и вызывает его в пуле потоков с использованием метода BeginInvoke().

Это отклонение от обычной философии дизайна «ямы успеха», где все в .NET, похоже, работает так, как вы думаете, без необходимости внимательно читать документацию и/или постепенно обнаруживать неясные уловы и gotchas со временем.

---

Я пытался найти информацию об использовании IO Completion Ports в .NET.

Есть ли хороший способ узнать, использует ли данный класс .NET Поля ввода-вывода IO? (Без необходимости запускать некоторые тесты каждый раз, когда вы используете новый класс.

Я попробовал документацию MSDN для некоторых классов и методов, и я не мог найти что-нибудь на нем.

Еще лучше, если бы есть список, содержащий список классов с использованием IOCP.

Answer 1

Как правило, BCL предлагает только асинхронные API, если они реализованы с использованием async IO, поддерживаемых ядром Windows. Выявление методов async, которые не используют async kernel-IO было бы известным асинхронным анти-шаблоном, о котором наверняка знают дизайнеры BCL. Это было бы не только бесполезно, но и вредно для производительности и вводить в заблуждение. Они не делают этого.

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

Все это прозрачно для вас. Полагайтесь на async, являющийся действительно асинхронным, и синхронизация действительно синхронизируется.

Если есть сомнения, загляните под капот с отражателем. Всякий раз, когда я это делал, я нашел подтверждение того, что я только что сказал. Мне еще предстоит увидеть отклоняющийся случай.

Что вы видите с рефлектором, так это то, что BCL вызывает асинхронные версии соответствующих API Win32.В качестве примера, я рассмотрю файлы и сокеты:

• FileStream.BeginRead косвенно вызывает Win32Native.ReadFileNative с указателем на NativeOverlapped структуру. Указатель получается путем вызова Overlapped.Pack. Обратный вызов завершения сохраняется таким образом. Невозможно определить способ вызова обратного вызова с помощью Reflector, поскольку эта часть существует в нативной части CLR. Я не могу сказать, используется ли IOCP, но я могу сказать, что используется async IO.
• Socket.BeginRead косвенно вызывает WSARecv. Код довольно сложный. BCL, похоже, может использовать перекрывающиеся IO, а также IOCP в зависимости от ОС. Проверка производится в Socket.InitializeSockets. Решение, какое IO использовать, хранится в Socket.UseOverlappedIO. Если эта переменная ложна, в конечном итоге вызывается Socket.BindToCompletionPort.

Итак, для разъемов это, очевидно, IOCP на современных ОС. Для файлов я не могу сказать.

Мне лично не очень интересно, какой асинхронный IO используется до тех пор, пока он не блокируется. В этом случае.

Answer 2

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

Итак, если вы хотите получить твердую гарантию, что они действительно используются, вам необходимо получить источник хоста CLR, который вы используете. Это трудно найти, их много, и вам нужно будет обратиться в Microsoft, чтобы получить доступ к источнику. В источнике доступен только хост SSCLI20, он устарел и охватывает только хост по умолчанию. Это было само по себе, чтобы позволить PAL предоставлять порт завершения ввода/вывода, безусловно, фактически не присутствовать в реальных хостах CLR, которые вы когда-либо запускали.

Вы не указали, какие платформы вы считаете. Некоторые guesstimates:

• ASP.NET: да, порты ввода/вывода завершающие большое дело для сокетов
• SQL Server: очень вероятно, но не Slamdunk, он не имеет сноровки делать вещи по-разному
• Рабочий стол: да, для любого .NET версии> = 2.0, которая работает на ветке NT
• Compact: определенно не
• Micro: определенно не
• XBox: маловероятно, детали OS являются большая тайна
• Silverlight: CoreCLR.dll для Windows используется, но нет ThreadPool.BindHandle
• Phone7: похожее на Silverlight
• Phone8: большая тайна, возможно.

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