Scheduling,ThreadContext,andIRQL资源-CSDN文库

需积分: 13 93 浏览量 2009-07-08 02:48:13 上传评论收藏 282KB DOC 举报

### 知识点详解 #### 一、绪论与线程调度 - **绪论**：本文档旨在探讨线程调度、线程上下文及处理器当前中断请求级别（IRQL）如何影响Microsoft Windows系列操作系统内核模式驱动程序的运行。这对于驱动程序开发者来说至关重要，因为了解这些基本概念能够帮助他们更好地编写高效且稳定的驱动。 - **线程调度**：在多任务操作系统中，线程调度机制负责决定哪个线程将在处理器上运行。它基于不同的算法和策略来确定线程的优先级和执行顺序。Windows操作系统采用了多种调度策略来确保不同类型的线程能够得到合理的处理时间，包括实时线程、交互式线程以及后台线程等。 #### 二、线程上下文与驱动程序例程 - **线程上下文**：每个线程都有自己的上下文环境，其中包含了线程执行时所需的所有状态信息，如寄存器值、栈指针等。当线程被切换时，其上下文会被保存并恢复。对于驱动程序而言，理解线程上下文是非常重要的，因为它直接影响到驱动程序例程的执行方式。 - **驱动程序例程**：驱动程序中的各种例程（如初始化例程、设备控制例程等）通常在特定的上下文中运行。例如，一些例程只能在低IRQL下执行，而另一些则可以在任何IRQL下运行。掌握这些细节对于避免潜在的同步问题和死锁非常重要。 #### 三、驱动程序线程 - **驱动程序线程概述**：驱动程序可以创建自己的线程来执行特定的任务，如异步I/O操作或响应设备事件。这些线程通常由操作系统管理，并且它们的执行受到线程调度机制的控制。合理地设计和管理这些线程可以显著提高驱动程序的性能和可靠性。 #### 四、中断请求级别（IRQL） - **IRQL概述**：中断请求级别是衡量处理器处理中断请求的能力的一个指标。在Windows操作系统中，不同的IRQL对应不同的中断处理能力。例如，低级别的IRQL允许更长时间的中断处理，而高级别的IRQL则要求中断处理尽可能快。 - **特定于处理器和线程的IRQL**：在单处理器系统中，整个系统的IRQL通常是一致的；而在多处理器系统中，则可能存在多个不同的IRQL。这意味着开发者需要根据处理器的具体配置来适配他们的代码。 - **特定的IRQL级别**： - **PASSIVE_LEVEL**：这是最低的IRQL级别，允许最长时间的执行，适用于大多数非中断相关的驱动程序例程。 - **APC_LEVEL**：比PASSIVE_LEVEL高一级，主要用于处理异步过程调用（APCs），不允许长时间的执行。 - **DISPATCH_LEVEL**：更高的IRQL级别，用于处理硬件中断和快速的调度操作。 - **DIRQL**：特定于某些设备驱动程序的IRQL，用于处理特定设备的中断。 - **HIGH_LEVEL**：最高的IRQL级别，用于确保关键操作能够立即完成。 - **运行在DISPATCH_LEVEL或更高IRQL的指导原则**：由于这些IRQL级别要求中断处理必须迅速完成，因此编写在这类IRQL级别下运行的代码时需要特别小心，避免长时间的操作。 - **改变驱动程序代码运行的IRQL**：有时可能需要改变驱动程序代码运行的IRQL以满足特定的需求或优化性能。这通常涉及到使用特定的API函数来调整IRQL。 #### 五、标准驱动程序例程、IRQL与线程上下文 - **标准驱动程序例程**：许多Windows驱动程序例程都是在特定的IRQL级别下运行的，比如在PASSIVE_LEVEL下执行的初始化例程，或者在DISPATCH_LEVEL下执行的中断服务例程。理解这些例程的IRQL需求有助于避免错误。 - **示例**：文档中提供了两个具体的例子，一个是在单处理器系统中如何处理中断，另一个是在多处理器系统中如何处理中断。通过这些例子，读者可以更好地理解在不同处理器配置下的中断处理机制。 #### 六、测试IRQL问题 - **查找当前IRQL的技术**：为了诊断与IRQL相关的编程错误，开发人员需要知道当前正在运行的代码处于哪个IRQL级别。文档提供了一些方法，如使用`PAGED_CODE`宏来判断当前是否处于非分页内存区域，从而推断出当前的IRQL级别。 - **Driver Verifier选项**：Driver Verifier是Windows操作系统提供的一种工具，用于检测驱动程序中存在的问题。它可以用来模拟不同的IRQL条件，帮助开发者找出潜在的问题。 - **最佳实践**：文档还提出了一些最佳实践建议，以帮助驱动程序开发者避免常见的IRQL相关问题，如确保在适当的IRQL级别下调用正确的API函数等。 #### 结语与资源 - **行动呼吁与资源**：文档鼓励开发者深入研究这些概念，并提供了进一步学习的资源链接，如关于锁、死锁和同步的补充文档。这些资源对于希望深入了解Windows内核模式驱动程序的开发者来说非常宝贵。 #### 免责声明 - **免责声明**：文档明确指出其为初步版本，在最终发布前可能会有重大修改。此外，文档中的信息仅用于信息目的，并不构成微软的任何承诺。微软不对文档中提供的信息在发布日期之后的准确性承担责任。

资源推荐

资源详情

资源评论

Scheduling, Thread Context, 
andIRQL
August 5, 2021
Abstract
This paper presents information about how thread scheduling, thread context, and a
processor’s current interrupt request level (IRQL) affect the operation of kernel-
mode drivers for the Microsoft® Windows® family of operating systems. It is 
intended to provide driver writers with a greater understanding of the environment in
which their code runs.
A companion paper, “Locks, Deadlocks, and Synchronization” at 
http://www.microsoft.com/whdc/hwdev/driver/LOCKS.mspx, builds on these 
fundamental concepts to address synchronization issues in drivers.
Contents
Thread Scheduling....................................................................................................................3
Thread Context and Driver Routines........................................................................................4
Driver Threads..........................................................................................................................5
Interrupt Request Levels...........................................................................................................6
Processor-specific and Thread-specific IRQLs....................................................................8
IRQL PASSIVE_LEVEL..................................................................................................8
IRQL PASSIVE_LEVEL in a critical region.....................................................................9
IRQL APC_LEVEL..........................................................................................................9
IRQL DISPATCH_LEVEL..............................................................................................10
IRQL DIRQL..................................................................................................................11
IRQL HIGH_LEVEL.......................................................................................................12
Guidelines for Running at IRQL DISPATCH_LEVEL or Higher.........................................13
Changing the IRQL at which Driver Code Runs.................................................................13
Standard Driver Routines, IRQL, and Thread Context.......................................................14
Interrupting a Thread: Examples.............................................................................................17
Single-Processor Example.................................................................................................17
Multiprocessor Example.....................................................................................................18
Testing for IRQL Problems.....................................................................................................20
Techniques for Finding the Current IRQL..........................................................................20
PAGED_CODE Macro.......................................................................................................20
Driver Verifier Options........................................................................................................21
Best Practices for Drivers.......................................................................................................21
Call to Action and Resources..................................................................................................21

Understanding Scheduling, Thread Context, and IRQL -- 2

Disclaimer

This is a preliminary document and may be changed substantially prior to final commercial release of the

software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the

issues discussed as of the date of publication. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot

guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,

EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights

under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval

system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or

otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property

rights covering subject matter in this document. Except as expressly provided in any written license

agreement from Microsoft, the furnishing of this document does not give you any license to these

patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail

addresses, logos, people, places and events depicted herein are fictitious, and no association with any

real company, organization, product, domain name, email address, logo, person, place or event is

intended or should be inferred.

Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft

Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their

respective owners.

Understanding Scheduling, Thread Context, and IRQL -- 3

Introduction

Thread scheduling, thread context, and the current interrupt request level (IRQL) for

each processor have important effects on how drivers work.

A thread’s scheduling priority and the processor’s current IRQL determine whether

a running thread can be pre-empted or interrupted. In thread pre-emption, the

operating system replaces the running thread with another thread, usually of higher

thread priority, on the same processor. The effect of pre-emption on an individual

thread is to make the processor unavailable for a while. In thread interruption, the

operating system forces the current thread to temporarily run code at a higher

interrupt level. The effect of interruption on an individual thread is similar to that of a

forced procedure call.

Interruption and pre-emption both affect how code that runs in the thread can

access data structures, use locks, and interact with other threads. Understanding

the difference is crucial in writing kernel-mode drivers. To avoid related problems,

driver writers should be familiar with:

 The thread scheduling mechanism of the operating system

 The thread context in which driver routines can be called

 The appropriate use of driver-dedicated and system worker threads

 The significance of various IRQLs and what driver code can and cannot do

at each IRQL

Thread Scheduling

The Microsoft® Windows® operating system schedules individual threads, not

entire processes, for execution. Every thread has a scheduling priority (its thread

priority), which is a value from 0 to 31, inclusive. Higher numbers indicate higher

priority threads.

Each thread is scheduled for a quantum, which defines the maximum amount of

CPU time for which the thread can run before the kernel looks for other threads at

the same priority to run. The exact duration of a quantum varies depending on what

version of Windows is installed, the type of processor on which Windows is running,

and the performance settings that have been established by a system administrator.

(For more details, see Inside Windows 2000.)

After a thread is scheduled, it runs until one of the following occurs:

 Its quantum expires.

 It enters a wait state.

 A higher-priority thread becomes ready to run.

Kernel-mode threads do not have priority over user-mode threads. A kernel-mode

thread can be pre-empted by a user-mode thread that has a higher scheduling

priority.

Thread priorities in the range 1-15 are called dynamic priorities. Thread priorities in

the range from 16-31 are called real-time priorities. Thread priority zero is reserved

for the zero-page thread, which zeroes free pages for use by the memory manager.

Every thread has a base priority and a current priority. The base priority is usually

inherited from the base priority for the thread’s process. The current priority is the

thread’s priority at any given time. For kernel-mode driver code that runs in the

context of a user thread, the base priority is the priority of the user process that

Understanding Scheduling, Thread Context, and IRQL -- 4

originally requested the I/O operation. For kernel-mode driver code that runs in the

context of a system worker thread, such as a work item, the base priority is the

priority of the system worker threads that service its queue.

To improve system throughput, the operating system sometimes adjusts thread

priorities. If a thread’s base priority is in the dynamic range, the operating system

can temporarily increase (“boost”) or decrease its priority, thus making its current

priority different from its base priority. If a thread’s base priority is in the real-time

range, its current priority and base priority are always the same; threads running at

real-time priorities never receive a priority boost. In addition, a thread that is running

at a dynamic priority can never be boosted to a real-time priority. Therefore,

applications that create threads with base priorities in the real-time range can be

confident that these threads always have a higher priority than those in the dynamic

range.

The system boosts a thread’s priority when the thread completes an I/O request,

when it stops waiting for an event or semaphore, or when it has not been run for

some time despite being ready to run (called “CPU starvation”). Threads involved in

the Graphical User Interface (GUI) and the user’s foreground process also receive a

priority boost in some situations. The amount of the increase depends on the

reason for the boost and, for I/O operations, on the type of device involved. Drivers

can affect the boost their code receives by:

 Specifying a priority boost in the call to IoCompleteRequest.

 Specifying a priority increment in the call to KeSetEvent, KePulseEvent,

KeReleaseSemaphore.

Constants defined in ntddk.h and wdm.h indicate the appropriate priority boost for

each device, event, and semaphore.

A thread’s scheduling priority is not the same as the interrupt request level (IRQL)

at which the processor operates.

Thread Context and Driver Routines

Most Windows drivers do not create threads; instead, a driver consists of a group of

routines that are called in an existing thread that was created by an application or

system component.

Kernel-mode software developers use the term “thread context” in two slightly

different ways. In its narrowest meaning, thread context is the value of the thread’s

CONTEXT structure. The CONTEXT structure contains the values of the hardware

registers, the stacks, and the thread’s private storage areas. The exact contents

and layout of this structure will vary according to the hardware platform. When

Windows schedules a user thread, it loads information from the thread’s CONTEXT

structure into the user-mode address space.

From a driver developer’s perspective, however, “thread context” has a broader

meaning. For a driver, the thread context includes not only the values stored in the

CONTEXT structure, but also the operating environment they define—particularly,

the security rights of the calling application. For example, a driver routine might be

called in the context of a user-mode application, but it can in turn call a ZwXxx

routine to perform an operation in the context of the operating system kernel. This

paper uses “thread context” in this broader meaning.

The thread context in which driver routines are called depends on the type of

device, on the driver’s position in the device stack, and on the other activities

currently in progress on the system. When a driver routine is called to perform an

剩余21页未读，继续阅读

评论收藏

内容反馈

Zylinkultamyyrä

粉丝: 10
资源: 103

Scheduling, Thread Context, and IRQL

Scheduling, Thread Context, and IRQL.pdf

Scheduling, Thread Context, and IRQL.doc

Advanced Planning and Scheduling in Manufacturing and Supply Chains

Scheduling, Thread Context and Synchronization - Windows Hardware and Driver Central (2004)-计算机科学

Multiprocessor Scheduling: Theory and Applications

Multiprocessor Scheduling Theory and Applications 2014

OracleMaster Scheduling/MRP and Oracle Supply Chain Planning Us

Scheduling Theory Algorithms and Systems 2008

Optimal-Scheduling-for-Charging-and-Discharging-of-Electric-Vehicles-master.zip

Planning and Scheduling

Principles of Sequencing and Scheduling 2nd edition 2018

Detailed Scheduling and Planning ECM Preview.

Developing Drivers with the Microsoft Windows Driver Foundation

Scheduling, Timetabling and Routing

Real-Time Systems Architecture Scheduling and Application 2016

Scheduling-Theory, Algorithms and Systems

Scheduling-Theory, Algorithms and Systems(2008).pdf

Task Scheduling for Multi-core and Parallel Architectures 2017

Scheduling Theory, Algorithms, and Systems Third Edition

Airline operations and scheduling

scheduling simulation in java

SAP S4HANA 1909 for TM-Scheduling Agreement and Freight Cost.mhtml

Advanced Planning and Scheduling

Apollo: Scalable and Coordinated Scheduling for Cloud-Scale Computing

Scheduling

Timing Optimization Through Clock Skew Scheduling

最新资源