Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
 |  |
Спасибо, про отдельную очередь понятно. Но задача такова,... 03.05.05 21:16 Число просмотров: 1899
Автор: 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 обработка (как же это по русски то?).
|
<programming>
|
[Win32] Dispatch routine для DeviceIoControl 02.05.05 14:51
Автор: serge Статус: Незарегистрированный пользователь
|
Оказывается subj вызывается синхронно, т.е. последующий irp не приходит, пока не выйдет предыдущий...
А нельзя ли организовать асинхронную его работу без значительных изменений? А то в user mode коде вызов DeviceIoControl в одном thread'е используется для синхронизации, а другой не должен из-за этого блокироваться.
|
 |
[Win32] Открывай устройство с file_flag_overlapped 04.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/с выделенным спинлоком, во всех остальных случаях обрабатывать можно столько сколько нужно.
> А для синхронизации мутексы существуют. Для синхронизации есть много чего, а ввод/вывод в большинстве случаев принципиально может быть только асинхронным.
|
|
|