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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Спасибо, про отдельную очередь понятно. Но задача такова,... 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/с выделенным спинлоком, во всех остальных случаях обрабатывать можно столько сколько нужно.

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




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


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