Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
О чем и говорю, 05.05.05 12:50 Число просмотров: 1929
Автор: Zef <Alloo Zef> Статус: Elderman
|
Что подобная "синхронизация" - в высшей степени дурной тон. IRP надо освобождать как можно быстрее. И в DeviceIOCtrl задерживаться нехорошо.
А для синхронизации мутексы существуют.
|
|
<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/с выделенным спинлоком, во всех остальных случаях обрабатывать можно столько сколько нужно.
> А для синхронизации мутексы существуют.
Для синхронизации есть много чего, а ввод/вывод в большинстве случаев принципиально может быть только асинхронным.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
