> Делать вытеснение или поддержку приоритетов для fiber-ов не > нужно "по определению". При выполнении кода в fiber все > сводиться к тому, что вместо засыпания по WaitFor > происходит переключение на другой стек/контекст, но все это > преимущественно в одном thread и без использования > kernel-dispatch. > > Обработка Power-Managenet IRP не допускает прямого ожидания > (IRQL may == DISPATCH_LEVEL), только STATUS_PENDING. Но для > functional devices при выключении необходимо как минимум > дождаться IoDone, поэтому асинхронного выполнение IRP в > IoWorkItem или отдельном thread не избежать. > > Для Bus драйвера задействование IoWorkItem в > Power-Management может приводить к "мягкому" dead-lock > (компьютер бесконечно долго выключает питание). Поэтому > необходимо обслуживать IRP в персональном thread, но это > достаточно дорого, особенно когда 100-200 child-devices. > > Именно поэтому я сделал fibers: Логика выполнения как-будно > в персональном thread (или IoWorkItem), но при этом thread > только один.
> Суть моего вопроса была в другом - что плохого может быть > при подмене стека ядра, без обновления полей в системном > thread-объекте. Ну конечно кроме очевидных вещей, как > например то, что IoGetStackLimits() и IoGetInitialStack() > теряют актуальность, или отслеживание APC_LEVEL при > переброске fiber-ов между threads. Как я понимаю вам просто на диспетч для ускорения выключения необходимо "паралельно ожидать" завершения некоторых действий?
Насколько я помню в структуре ктреда нет полей, жестко привязанных с текущему стеку ядра. А возможные проблемы - (возможно) использование переменных ядра, сервисов, использующих эти переменные, эксепшены....всего, что может быть жестко привязано к стеку.
это все лежит за рамками документированного M$ и проверяется только.......опытом=) Вот зачем только надо перезагружать стек, я думаю без этого можно обойтись.
Для управления питанием bus-fdo и child-pdo в драйвере с большим количеством дочерних устройств, реализовал fiber-ы в режиме ядра (см. fibers в pladform sdk/mdsn).
Так сложно потому, что создавать thread на каждый irp - слишком расточительно, а использование work-items порождает dead-locks.
Пока работает, и даже с driver verifier-ом:). Но ради простоты я "наплевал" на user-mode-stack, кроме этого конечно умер stack-grow, и наверное еще что-нибудь. Поэтому и ВОПРОС: кто-нибудь делал что-либо подобное, или слышал? Может есть известные проблемы?
Исходники NT4 и W2K я конечно просмотрю, но много их...
Сомневаюсь, что ты эффективно сделал переключение нитей...05.03.04 14:55 Автор: Sergio Статус: Незарегистрированный пользователь
> Для управления питанием bus-fdo и child-pdo в драйвере с > большим количеством дочерних устройств, реализовал fiber-ы > в режиме ядра (см. fibers в pladform sdk/mdsn). > Так сложно потому, что создавать thread на каждый irp - > слишком расточительно, а использование work-items порождает > dead-locks. > > Пока работает, и даже с driver verifier-ом:). Но ради > простоты я "наплевал" на user-mode-stack, кроме этого > конечно умер stack-grow, и наверное еще что-нибудь. Поэтому > и ВОПРОС: кто-нибудь делал что-либо подобное, или слышал? > Может есть известные проблемы? > > Исходники NT4 и W2K я конечно просмотрю, но много их...
Сомневаюсь, что ты эффективно сделал переключение нитей. Если нити переключаются не через последовательный опрос то может кинешь поглядеть %) Подробнее про проблему можно зачем на каждый irp свой поток/нить? Сомневаюсь что нужно это было делать... У меня тоже пока работает таймаут по отсутствию (для простоты скажем) одного из шести прерываний и это работает в отдельном потоке с последовательным опросом (можно тоже сказать нити).....а реально и правильней делать в моем случае через кэнселейшн.
ЗЫ
C DV должно проходить и *NULL = NULL;
Делать вытеснение или поддержку приоритетов для fiber-ов не...05.03.04 16:39 Автор: leo <Леонид Юрьев> Статус: Elderman
> Сомневаюсь, что ты эффективно сделал переключение нитей. > Если нити переключаются не через последовательный опрос то > может кинешь поглядеть %) Подробнее про проблему можно > зачем на каждый irp свой поток/нить? Сомневаюсь что нужно > это было делать... У меня тоже пока работает таймаут по > отсутствию (для простоты скажем) одного из шести прерываний > и это работает в отдельном потоке с последовательным > опросом (можно тоже сказать нити).....а реально и > правильней делать в моем случае через кэнселейшн.
Делать вытеснение или поддержку приоритетов для fiber-ов не нужно "по определению". При выполнении кода в fiber все сводиться к тому, что вместо засыпания по WaitFor происходит переключение на другой стек/контекст, но все это преимущественно в одном thread и без использования kernel-dispatch.
Обработка Power-Managenet IRP не допускает прямого ожидания (IRQL may == DISPATCH_LEVEL), только STATUS_PENDING. Но для functional devices при выключении необходимо как минимум дождаться IoDone, поэтому асинхронного выполнение IRP в IoWorkItem или отдельном thread не избежать.
Для Bus драйвера задействование IoWorkItem в Power-Management может приводить к "мягкому" dead-lock (компьютер бесконечно долго выключает питание). Поэтому необходимо обслуживать IRP в персональном thread, но это достаточно дорого, особенно когда 100-200 child-devices.
Именно поэтому я сделал fibers: Логика выполнения как-будно в персональном thread (или IoWorkItem), но при этом thread только один.
Если вы не написали "с нуля" и не отладили хотя-бы один bus-дайвер с полной поддержкой управления питанием, то понять зачем мне понадобились fibers достаточно сложно. В M$ в таких случаях говорят однозначно – каждый SET/QUERY_POWER IRP выполнять в отдельном потоке, а я вот решил сделать «хитрее».
Cancellation тут совершенно ни при чем, в вашем случае можно уверенно обойтись и без thread (что будет дешевле для системы в целом).
Суть моего вопроса была в другом - что плохого может быть при подмене стека ядра, без обновления полей в системном thread-объекте. Ну конечно кроме очевидных вещей, как например то, что IoGetStackLimits() и IoGetInitialStack() теряют актуальность, или отслеживание APC_LEVEL при переброске fiber-ов между threads.
Как я понимаю вам просто на диспетч для ускорения...06.03.04 14:47 Автор: Sergio Статус: Незарегистрированный пользователь
> Делать вытеснение или поддержку приоритетов для fiber-ов не > нужно "по определению". При выполнении кода в fiber все > сводиться к тому, что вместо засыпания по WaitFor > происходит переключение на другой стек/контекст, но все это > преимущественно в одном thread и без использования > kernel-dispatch. > > Обработка Power-Managenet IRP не допускает прямого ожидания > (IRQL may == DISPATCH_LEVEL), только STATUS_PENDING. Но для > functional devices при выключении необходимо как минимум > дождаться IoDone, поэтому асинхронного выполнение IRP в > IoWorkItem или отдельном thread не избежать. > > Для Bus драйвера задействование IoWorkItem в > Power-Management может приводить к "мягкому" dead-lock > (компьютер бесконечно долго выключает питание). Поэтому > необходимо обслуживать IRP в персональном thread, но это > достаточно дорого, особенно когда 100-200 child-devices. > > Именно поэтому я сделал fibers: Логика выполнения как-будно > в персональном thread (или IoWorkItem), но при этом thread > только один.
> Суть моего вопроса была в другом - что плохого может быть > при подмене стека ядра, без обновления полей в системном > thread-объекте. Ну конечно кроме очевидных вещей, как > например то, что IoGetStackLimits() и IoGetInitialStack() > теряют актуальность, или отслеживание APC_LEVEL при > переброске fiber-ов между threads. Как я понимаю вам просто на диспетч для ускорения выключения необходимо "паралельно ожидать" завершения некоторых действий?
Насколько я помню в структуре ктреда нет полей, жестко привязанных с текущему стеку ядра. А возможные проблемы - (возможно) использование переменных ядра, сервисов, использующих эти переменные, эксепшены....всего, что может быть жестко привязано к стеку.
это все лежит за рамками документированного M$ и проверяется только.......опытом=) Вот зачем только надо перезагружать стек, я думаю без этого можно обойтись.
Re: зачем только надо перезагружать стек, я думаю07.03.04 14:50 Автор: leo <Леонид Юрьев> Статус: Elderman Отредактировано 07.03.04 17:50 Количество правок: 1
> > Вот зачем только надо > > перезагружать стек, я думаю без этого можно обойтись. > > Извините, но у меня создалось впечатление, что вы либо не > внимательно читаете мои сообщения, либо недостаточно > компетентны чтобы говорить на эту тему.
Я никогда не писал шинных драйверов и поэтому совершенно не представляю проблем возникающих при их написании.
Вы просто попробуйте простым языком в ДВУХ словах обьяснить что требуется. Как я понимаю Вам на уровне диспетч требуется ожидать завершение работы от нескольких устройст. Вы сделали это через реализацию нитей. Ок. Проблемы то какие? Опыт вам нужен? У меня такого нет.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
