Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Как я понимаю вам просто на диспетч для ускорения... 06.03.04 14:47 Число просмотров: 1187
Автор: 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$ и проверяется только.......опытом=) Вот зачем только надо перезагружать стек, я думаю без этого можно обойтись.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
