информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsГде водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Задержанный IRP никак не влияет на производительность... 04.05.05 14:28  Число просмотров: 1841
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Кстати, я так и делал. Чтобы не тормозить ядро, копировал
> данные, освобождал irp и "пережевывал" их в отдельном

Задержанный IRP никак не влияет на производительность системы. Более того, это один из самых правильных способов синхронизации с ядром

> потоке. А вот синхронизировать юзверские потоки таким
> образом, как у тебя не следует. Задерживать возврат из
> DeviceIoCtl допустимо только по "системным показаниям", а

Нет, например IOCTL_SERIAL_WAIT_ON_MASK работает именно так. Да и IRP_MJ_READ/IRP_MJ_WRITE в большинстве случаев возвращают STATUS_PENDING и только через некоторое время завершаются

> пользователя надо синхронизировать мутексами.
<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/с выделенным спинлоком, во всех остальных случаях обрабатывать можно столько сколько нужно.

> А для синхронизации мутексы существуют.
Для синхронизации есть много чего, а ввод/вывод в большинстве случаев принципиально может быть только асинхронным.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach