Спасибо, про отдельную очередь понятно. Но задача такова,...03.05.05 21:16 Число просмотров: 2037 Автор: serge Статус: Незарегистрированный пользователь Отредактировано 03.05.05 21:18 Количество правок: 1
> Прально! Это для того и сделано, чтобы останавливать > систему в том случае, если от успешности обработки данного > irp-а зависит ее дальнейшая работа. Если тебе не нужно ее > блокировать, то организуй отдельную очередь и обработчик в > отдельном потоке. А в сабже только копируй в эту очередь > данные и сразу выходи.
Спасибо, про отдельную очередь понятно. Но задача такова, что обработчик irp пакетов используется для синхронизации user и kernel mode кода. Судя по ответу, организовать синхронизацию с помощью вызовов DeviceIoControl мне не удастся. Какие ещё способы синхронизации существуют?
Для наглядности вот временная диаграмма того, что мне нужно получить:
00:01 DevIoCtl Called from thread1
00:02 DevIoCtl Called from thread2
00:03 DevIoCtl Returned from thread2
00:05 DevIoCtl Returned from thread1
Наверное я неправильно выразился, говоря что мне нужна асинхронная обработка irp. Мне нужна concurrent обработка (как же это по русски то?).
Оказывается subj вызывается синхронно, т.е. последующий irp не приходит, пока не выйдет предыдущий...
А нельзя ли организовать асинхронную его работу без значительных изменений? А то в user mode коде вызов DeviceIoControl в одном thread'е используется для синхронизации, а другой не должен из-за этого блокироваться.
[Win32] Открывай устройство с file_flag_overlapped04.05.05 14:24 Автор: amirul <Serge> Статус: The Elderman
> А нельзя ли организовать асинхронную его работу без > значительных изменений? А то в user mode коде вызов
В DeviceIoControl передавай OVERLAPPED структуру. Дальше ждешь на событии, которое забил в эту структуру или просто делаешь периодически GetOverlappedResult
> DeviceIoControl в одном thread'е используется для > синхронизации, а другой не должен из-за этого > блокироваться.
Прально! Это для того и сделано, чтобы останавливать систему...03.05.05 04:40 Автор: Zef <Alloo Zef> Статус: Elderman
> Оказывается subj вызывается синхронно, т.е. последующий irp > не приходит, пока не выйдет предыдущий... > А нельзя ли организовать асинхронную его работу без > значительных изменений? А то в user mode коде вызов > DeviceIoControl в одном thread'е используется для > синхронизации, а другой не должен из-за этого > блокировать
Прально! Это для того и сделано, чтобы останавливать систему в том случае, если от успешности обработки данного irp-а зависит ее дальнейшая работа. Если тебе не нужно ее блокировать, то организуй отдельную очередь и обработчик в отдельном потоке. А в сабже только копируй в эту очередь данные и сразу выходи.
Спасибо, про отдельную очередь понятно. Но задача такова,...03.05.05 21:16 Автор: serge Статус: Незарегистрированный пользователь Отредактировано 03.05.05 21:18 Количество правок: 1
> Прально! Это для того и сделано, чтобы останавливать > систему в том случае, если от успешности обработки данного > irp-а зависит ее дальнейшая работа. Если тебе не нужно ее > блокировать, то организуй отдельную очередь и обработчик в > отдельном потоке. А в сабже только копируй в эту очередь > данные и сразу выходи.
Спасибо, про отдельную очередь понятно. Но задача такова, что обработчик irp пакетов используется для синхронизации user и kernel mode кода. Судя по ответу, организовать синхронизацию с помощью вызовов DeviceIoControl мне не удастся. Какие ещё способы синхронизации существуют?
Для наглядности вот временная диаграмма того, что мне нужно получить:
00:01 DevIoCtl Called from thread1
00:02 DevIoCtl Called from thread2
00:03 DevIoCtl Returned from thread2
00:05 DevIoCtl Returned from thread1
Наверное я неправильно выразился, говоря что мне нужна асинхронная обработка irp. Мне нужна concurrent обработка (как же это по русски то?).
А кто мешает обрабатывать данные в ядре в отдельном потоке?04.05.05 04:19 Автор: Zef <Alloo Zef> Статус: Elderman
> Спасибо, про отдельную очередь понятно. Но задача такова, > что обработчик irp пакетов используется для синхронизации > user и kernel mode кода. Судя по ответу, организовать > синхронизацию с помощью вызовов DeviceIoControl мне не > удастся. Какие ещё способы синхронизации существуют? > > Для наглядности вот временная диаграмма того, что мне нужно > получить: > > 00:01 DevIoCtl Called from thread1 > 00:02 DevIoCtl Called from thread2 > 00:03 DevIoCtl Returned from thread2 > 00:05 DevIoCtl Returned from thread1
Кстати, я так и делал. Чтобы не тормозить ядро, копировал данные, освобождал irp и "пережевывал" их в отдельном потоке. А вот синхронизировать юзверские потоки таким образом, как у тебя не следует. Задерживать возврат из DeviceIoCtl допустимо только по "системным показаниям", а пользователя надо синхронизировать мутексами.
Задержанный IRP никак не влияет на производительность...04.05.05 14:28 Автор: amirul <Serge> Статус: The Elderman
> Кстати, я так и делал. Чтобы не тормозить ядро, копировал > данные, освобождал irp и "пережевывал" их в отдельном
Задержанный IRP никак не влияет на производительность системы. Более того, это один из самых правильных способов синхронизации с ядром
> потоке. А вот синхронизировать юзверские потоки таким > образом, как у тебя не следует. Задерживать возврат из > DeviceIoCtl допустимо только по "системным показаниям", а
Нет, например IOCTL_SERIAL_WAIT_ON_MASK работает именно так. Да и IRP_MJ_READ/IRP_MJ_WRITE в большинстве случаев возвращают STATUS_PENDING и только через некоторое время завершаются
> пользователя надо синхронизировать мутексами.
В крайнем случае IoCompleteRequest "отпускаешь" irp,04.05.05 05:27 Автор: Zef <Alloo Zef> Статус: Elderman
Затем обрабатываешь данные. Вот, не знаю, мона ли войти в DeviceIOCtrl, если еще не вышел из предыдущего... Но, если они и правда запускаются, как отдельные потоки, то их в ядре можно синхронизировать мутексами.
Реентрабельность - одно из требований к драйверам04.05.05 14:30 Автор: amirul <Serge> Статус: The Elderman
> Затем обрабатываешь данные. Вот, не знаю, мона ли войти в > DeviceIOCtrl, если еще не вышел из предыдущего... Но, если > они и правда запускаются, как отдельные потоки, то их в > ядре можно синхронизировать мутексами.
Можно входить сколько угодно раз, все равно обработка всех irp выполняется в контексте вызвавшего потока. А вот для завершения используются рабочие потоки ядра (но и их количество система при необходимости увеличивает)
О чем и говорю,05.05.05 12:50 Автор: Zef <Alloo Zef> Статус: Elderman
Что подобная "синхронизация" - в высшей степени дурной тон. IRP надо освобождать как можно быстрее. И в DeviceIOCtrl задерживаться нехорошо.
А для синхронизации мутексы существуют.
Я уже говорил когда то, что практически ВЕСЬ ввод/вывод в...05.05.05 14:31 Автор: amirul <Serge> Статус: The Elderman
> Что подобная "синхронизация" - в высшей степени дурной тон.
Я уже говорил когда то, что практически ВЕСЬ ввод/вывод в винде - асинхронный. То бишь обработчик просто ставит запрос в очередь (при необходимости выставляет CompletionRoutine) и возвращает STATUS_PENDING. А вызывающий поток дальше сам решает, блокироваться ему на ожидании завершения или делать чего то свое.
> IRP надо освобождать как можно быстрее. И в DeviceIOCtrl
Зачем? IRP это просто область памяти в неподкачиваемом пуле (не такая уж и большая стоит отметить). И освобождать ЗАПРОС НА ВВОД/ВЫВОД (I/O Request Packet) нужно только после того, как этот запрос удовлетворен или стало ясно, что он не может быть удовлетворен без ошибок.
> задерживаться нехорошо.
Задерживаться нельзя только на высоком IRQL/с выделенным спинлоком, во всех остальных случаях обрабатывать можно столько сколько нужно.
> А для синхронизации мутексы существуют. Для синхронизации есть много чего, а ввод/вывод в большинстве случаев принципиально может быть только асинхронным.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
