Активизация и Обслуживание dpc.
Происхождение программного прерывания уровня Dispatch_level распознается тогда, когда это прерывание становится наивысшим по уровню IRQL событием, ожидающим обработки на этом процессоре. Таким образом, после вызова функции KeInsertQueueDpc(), обычно в следующий раз, когда процессор готов возвратиться на уровень IRQL ниже dispatch_level, вместо этого он вернется на IRQL dispatch_level и попытается обработать содержимое Очереди DPC.
Замечание.
Как отмечено ранее в этой главе, IRQL DISPATCH_LEVEL используется как для диспетчеризации так и для обработки Очереди DPC. В NT V4, когда обработано прерывание уровня DISPATCH_LEVEL, сначала обслуживается вся очередь DPC, и затем вызывается Диспетчер для планирования выполнения следующего потока. Это разумно, потому что обработка, сделанная подпрограммой DPC, могла изменить состояние базы данных планирования потоков, например, делая работоспособным ожидающий до того поток.
Очередь DPC обслуживается Микроядром. Каждый раз, когда обслуживается Очередь DPC, обрабатываются все элементы Очереди DPC для текущего процессора. По одному за раз, Микроядро удаляет Объект DPC из начала очереди, и вызывает DeferredRoutine, указанную в объекте. Микроядро передает как параметры для DeferredRoutine указатель на Объект DPC, и содержимое полей DeferredContext, SystemArgument1 и SystemArgument2 Объекта DPC.
Поскольку Очередь DPC обслуживается на IRQL dispatch_level, подпрограммы DPC вызываются на IRQL dispatch_level. Поскольку Очередь DPC обслуживается всякий раз, когда IRQL dispatch_level является самым высокоприоритетным IRQL для обслуживания (например сразу после того, как отработала программа обработки прерывания и перед возвращением к прерванному потоку пользователя), функции DPC работают в контексте произвольного потока (arbitrary thread context). Под контекстом произвольного потока мы подразумеваем, что DPC выполняется в процессе и потоке, которые могут вообще не иметь никакого отношения к запросу, который обрабатывает DPC. Контекст выполнения описан более подробно в Главе 11, "Многоуровневая Модель Драйвера".
Подпрограмма DPC завершает обработку и возвращается. По возвращении из подпрограммы DPC, Микроядро пытается выбрать другой Объект DPC из Очереди DPC и обрабатывать его. Когда очередь DPC пуста, обработка DPC заканчивается. Микроядро переходит к вызову Диспетчера.
Многочисленные dpc Обращения
Каждый DPC описан конкретным Объектом DPC. В результате всякий раз, когда вызывается функция KeInsertQueueDpc() и выясняется, что переданный ей Объект DPC уже находится в той же самой Очереди DPC, функция KeInsertQueueDpc() просто возвращается (не выполняя никаких действий). Таким образом, всякий раз, когда Объект DPC уже находится в Очереди DPC, любые последующие попытки постановки в очередь того же самого Объекта DPC, осуществляемые до удаления Объекта DPC из очереди, игнорируются. Это имеет смысл, так как Объект DPC может физически быть включен только в одну Очередь DPC одновременно.
Может возникнуть очевидный вопрос: Что произойдет, когда сделан запрос постановки Объекта DPC в очередь, но система уже выполняет подпрограмму DPC, указанную этим Объектом DPC (на этом же или другом процессоре)? Ответ на этот вопрос может быть найден при внимательном чтении предыдущего раздела этой главы. Когда Микроядро обслуживает Очередь DPC, оно удаляет Объект DPC из головы очереди, и только потом вызывает подпрограмму DPC, указанную Объектом DPC. Таким образом, когда подпрограмма DPC вызвана, Объект DPC уже удален из Очереди DPC процессора. Поэтому, когда сделан запрос на постановку Объекта DPC в очередь и система находится внутри подпрограммы DPC, заданной в этом Объекте DPC, DPC ставится в очередь как обычно.