Господа, DDK рекомендует реализовывать механизм оповещения user-mode приложения из kernel-mode двумя путями: события и перевод IRP запроса в состояние PENDING. Вызов DeviceIoControl возможен в синхронном и асинхронном режиме. Как я понимаю, с точки зрения производительности ожидание события и завершения асинхронного вызова DeviceIoControl по затратам примерно одинаковые и обусловленны необходимостью переключения ожидающего приложения в режим ядра. А какие затраты получаются в результате вызова DeviceIoControl в синхронном режиме? И вообще, если верить дяде Рихтеру, переключение из UM в KM на процессорах Intel занимает до 1000 тактов. DeviceIoControl, теоретически, должен быть сопоставим с этой величиной, так как он тоже переводит приложение в режим ядра? Или механизм DeviceIoControl основан на чем-то другом?
Ну 1000 - ето преувеличено... Сам переход UM<->KM через шлюз Int 2Eh занимает намного меньше времени а sysеnter - ещё быстре, потому как интел всё время оптимизирует ети сложные переходы (вместе с механизмами проверок памяти, переключение задач и т. д.) Ет наверно самая подпрограмма DeviceIoControl столько тянет из-за кучи дополнительных проверок, синхро из ядром и т.д. На современных процах cам переход сравнительный со скоростью FPU, а может даже и быстрее.
1000 тактов было сказано про WaitForXXXObject функции, а не про сам переход. Если ждать событие или завершение асинхронного вызова функции, то, по-любому, будешь использовать эти функции. А вот про синхронный вызов DeviceIoControl я подобной информации не нашел. Придется юзать профайлер, для получения сравнительных характеристик. Просто я надеялся, вдруг кто-нибудь уже занимался этим вопросом.
В принцыпе в синхронном режыме ожыдание может быть и дольше чем 1000 тактов. Что ето за такой асинхронный ввод-вывод? Ведь DeviceIOControl CreateFile ReadFile и WriteFile - они всё синхронныене тоесть не вернут управление до тех пор пока драйвер не выполнит запрос. Так непонятно зачем использовать WaitFor...Object по отношению к дрову<->UserMode? Время выполнения запроса зависит лишь от драйвера (и управляемого им устройства).
Посмотрите последний параметр "LPOVERLAPPED lpOverlapped". Еще какие асинхронные. Если я туда передам объект-событие, то получу управление сразу, а реагировать на завершение буду в другом месте, аккурат с использованием Wait-функций.
Угу забыл об етом приколе Вообще-то есть смысл покопать и оценить время исполнения ентой функцыи поскольку буду сам с ней часто работать. Попробуем её продизасмить.
