请问在驱动中类似于应用中的Sleep或等待函数是什么啊？

如题，有哪些，各有什么区别，望各位大虾不吝赐教，谢谢！

KeDelayExecutionThread
The KeDelayExecutionThread routine puts the current thread into an alertable or nonalertable wait state for a given interval.

NTSTATUS
  KeDelayExecutionThread(
    IN KPROCESSOR_MODE  WaitMode,
    IN BOOLEAN  Alertable,
    IN PLARGE_INTEGER  Interval
    );
Parameters
WaitMode
Specifies the processor mode in which the caller is waiting, which can be either KernelMode or UserMode. Lower-level drivers should specify KernelMode.
Alertable
Specifies TRUE if the wait is alertable. Lower-level drivers should specify FALSE.
Interval
Specifies the absolute or relative time, in units of 100 nanoseconds, for which the wait is to occur. A negative value indicates relative time. Absolute expiration times track any changes in system time; relative expiration times are not affected by system time changes.
Headers
Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h.

Return Value
KeDelayExecutionThread returns one of the following values that describes how the delay was completed:

STATUS_SUCCESS
The delay completed because the specified interval elapsed.
STATUS_ALERTED
The delay completed because the thread was alerted.
STATUS_USER_APC
A user-mode APC was delivered before the given Interval expired.
Note that the NT_SUCCESS macro recognizes all of these status values as "success" values.

Comments
The expiration time is computed and the current thread is put in a wait state. When the specified interval has passed, the thread exits the wait state and is put in the ready state, becoming eligible for execution.

The Alertable parameter specifies whether the thread can be alerted and its wait state consequently aborted. If the value of this parameter is FALSE then the thread cannot be alerted, no matter what the value of the WaitMode parameter or the origin of the alert. The only exception to this rule is that of a terminating thread. A thread is automatically made alertable, for instance, when terminated by a user with a CTRL+C.

If the value of Alertable is TRUE and one of the following conditions is present, the thread will be alerted:

If the origin of the alert is an internal, undocumented kernel-mode routine used to alert threads.
The origin of the alert is a user-mode APC, and the value of the WaitMode parameter is UserMode.
In the first of these two cases, the thread’s wait is satisfied with a completion status of STATUS_ALERTED; in the second case, it is satisfied with a completion status of STATUS_USER_APC.

The thread must be alertable for a user-mode APC to be delivered. This is not the case for kernel-mode APCs. A kernel-mode APC can be delivered and executed even though the thread is not alerted. Once the APC's execution completes, the thread's wait resumes. A thread is never alerted, nor is its wait aborted, by the delivery of a kernel-mode APC.

The delivery of kernel-mode APCs to a thread that has called KeDelayExecutionThread does not depend on whether the thread can be alerted. If the kernel-mode APC is a special kernel-mode APC, then the APC is delivered provided that IRQL < APC_LEVEL. If the kernel-mode APC is a normal kernel-mode APC, then the APC is delivered provided that the following three conditions hold: (1) IRQL < APC_LEVEL, (2) no kernel-mode APC is in progress, and(3) the thread is not in a critical section.

If the WaitMode parameter is UserMode, the kernel stack can be swapped out during the wait. Consequently, a caller must never attempt to pass parameters on the stack when calling KeDelayExecutionThread using the UserMode argument.

It is especially important to check the return value of KeDelayExecutionThread when the WaitMode parameter is UserMode or Alertable is TRUE, because KeDelayExecutionThread might return early with a status of STATUS_USER_APC or STATUS_ALERTED.

All long term waits that can be aborted by a user should be UserMode waits and Alertable should be set to FALSE.

Where possible, Alertable should be set to FALSE and WaitMode should be set to KernelMode, in order to reduce driver complexity. The principal exception to this is when the wait is a long term wait.

The expiration time of the delay is expressed as either an absolute time at which the delay is to expire, or a time relative to the current system time. If the Interval parameter is a negative value, the expiration time is relative.

Callers of KeDelayExecutionThread must be running at IRQL = PASSIVE_LEVEL.

KeWaitForMultipleObjects
The KeWaitForMultipleObjects routine puts the current thread into an alertable or nonalertable wait state until any or all of a number of dispatcher objects are set to a signaled state or (optionally) until the wait times out.

NTSTATUS
  KeWaitForMultipleObjects(
    IN ULONG  Count,
    IN PVOID  Object[],
    IN WAIT_TYPE  WaitType,
    IN KWAIT_REASON  WaitReason,
    IN KPROCESSOR_MODE  WaitMode,
    IN BOOLEAN  Alertable,
    IN PLARGE_INTEGER  Timeout  OPTIONAL,
    IN PKWAIT_BLOCK  WaitBlockArray  OPTIONAL
    );
Parameters
Count
Specifies the number of objects to be waited on.
Object
Pointer to an array of pointers to dispatcher objects (events, mutexes, semaphores, threads, and timers) for which the caller supplies the storage.
WaitType
Specifies either WaitAll, indicating that all of the specified objects must attain a signaled state before the wait is satisfied; or WaitAny, indicating that any one of the objects must attain a signaled state before the wait is satisfied.
WaitReason
Specifies the reason for the wait. Drivers should set this value to Executive or, if the driver is doing work on behalf of a user and is running in the context of a user thread, to UserRequest.
WaitMode
Specifies whether the caller waits in KernelMode or UserMode. Intermediate and lowest-level drivers should specify KernelMode. If the set of objects waited on includes a mutex, the caller must specify KernelMode.
Alertable
Specifies a Boolean value that indicates whether the thread can be alerted while it is in the waiting state.
Timeout
Pointer to an absolute or relative value representing the upper limit for the wait. A negative value specifies an interval relative to the current system time. The value should be expressed in units of 100 nanoseconds. Absolute expiration times track any changes in the system time; relative expiration times are not affected by system time changes.
WaitBlockArray
If Count <= THREAD_WAIT_OBJECTS, then WaitBlockArray can be NULL. Otherwise this parameter must point to a memory buffer of sizeof(KWAIT_BLOCK) * Count bytes. The routine uses this buffer for record-keeping while performing the wait operation.
Return Value
KeWaitForMultipleObjects can return one of the following:

STATUS_SUCCESS
Depending on the specified WaitType, one or all of the dispatcher objects in the Object array satisfied the wait.
STATUS_ALERTED
The wait is completed because of an alert to the thread.
STATUS_USER_APC
A user APC was delivered to the current thread before the specified Timeout interval expired.
STATUS_TIMEOUT
A time out occurred before the specified set of wait conditions was met. This value can be returned when an explicit time-out value of zero is specified, but the specified set of wait conditions cannot be met immediately.
Note that the NT_SUCCESS macro recognizes all of these status values as "success" values.

If KeWaitForMultipleObjects returns STATUS_SUCCESS and if WaitAny is specified as the WaitType, KeWaitForMultipleObjects also returns the zero-based index of the object that satisfied the wait at NTSTATUS.

Headers
Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h.

Comments
Each thread object has a built-in array of wait blocks that can be used to wait on several objects concurrently. Whenever possible, the built-in array of wait blocks should be used in a wait-multiple operation because no additional wait block storage needs to be allocated and later deallocated. However, if the number of objects that must be waited on concurrently is greater than the number of built-in wait blocks, use the WaitBlockArray parameter to specify an alternate set of wait blocks to be used in the wait operation. Drivers only need to allocate a sufficiently-large memory buffer for WaitBlockArray. The buffer does not need to be initialized, and the drivers can treat it as an opaque structure. The buffer can be freed once the routine returns.

If either Count > MAXIMUM_WAIT_OBJECTS or if WaitBlockArray is NULL and Count > THREAD_WAIT_OBJECTS, the system issues Bug Check 0xC (MAXIMUM_WAIT_OBJECTS_EXCEEDED).

The current state for each of the specified objects is examined to determine whether the wait can be satisfied immediately. If the necessary side effects are performed on the objects, an appropriate value is returned.

If the wait cannot be satisfied immediately and either no time-out value or a nonzero time-out value has been specified, the current thread is put in a waiting state and a new thread is selected for execution on the current processor. If no Timeout is supplied, the calling thread will remain in a wait state until the conditions specified by Object and WaitType are satisfied.

If Timeout is specified, the wait will be automatically satisfied if none of the specified wait conditions is met when the given interval expires.

A Timeout value of zero allows the testing of a set of wait conditions, conditionally performing any side effects if the wait can be immediately satisfied, as in the acquisition of a mutex.

The Alertable parameter specifies whether the thread can be alerted and its wait state consequently aborted. If the value of this parameter is FALSE then the thread cannot be alerted, no matter what the value of the WaitMode parameter or the origin of the alert. The only exception to this rule is that of a terminating thread. A thread is automatically made alertable, for instance, when terminated by a user with a CTRL+C.

If the value of Alertable is TRUE and one of the following conditions exists, the thread will be alerted:

If the origin of the alert is an internal, undocumented kernel-mode routine used to alert threads.
If the origin of the alert is a user-mode APC and the value of the WaitMode parameter is UserMode.
In the first of these two cases, the thread’s wait is satisfied with a completion status of STATUS_ALERTED; in the second case, it is satisfied with a completion status of STATUS_USER_APC.

The thread must be alertable for a user-mode APC to be delivered. This is not the case for kernel-mode APCs. A kernel-mode APC can be delivered and executed even though the thread is not alerted. Once the APC's execution completes, the thread's wait will resume. A thread is never alerted nor is its wait aborted by the delivery of a kernel-mode APC.

The delivery of kernel-mode APCs to a waiting thread does not depend on whether the thread can be alerted, but it depends on other conditions. If the kernel-mode APC is a special kernel-mode APC, then the APC is delivered provided that IRQL < APC_LEVEL. If the kernel-mode APC is a normal kernel-mode APC, then the APC is delivered provided that the following three conditions hold: (1) IRQL < APC_LEVEL, (2) no kernel APC is in progress, and (3) the thread is not in a critical section.

A special consideration applies when the Object parameter passed to KeWaitForMultipleObjects is a mutex. If the dispatcher object waited on is a mutex, APC delivery is the same as for all other dispatcher objects during the wait. However, once KeWaitForMultipleObjects returns with STATUS_SUCCESS and the thread actually holds the mutex, only special kernel-mode APCs are delivered. Delivery of all other APCs, both kernel-mode and user-mode, is disabled. This restriction on the delivery of APCs persists until the mutex is released.

For additional information, see Do Waiting Threads Receive Alerts and APCs?

If the WaitMode parameter is UserMode, the kernel stack can be swapped out during the wait. Consequently, a caller must never attempt to pass parameters on the stack when calling KeWaitForMultipleObjects with the UserMode argument. If you allocate the event on the stack, you must set the WaitMode parameter to KernelMode.

It is especially important to check the return value of KeWaitForMultipleObjects when the WaitMode parameter is UserMode or Alertable is TRUE, because KeWaitForMultipleObjects might return early with a status of STATUS_USER_APC or STATUS_ALERTED.

All long term waits that can be aborted by a user should be UserMode waits and Alertable should be set to FALSE.

Where possible, Alertable should be set to FALSE and WaitMode should be set to KernelMode, in order to reduce driver complexity. The principal exception to this is when the wait is a long term wait.

Callers of KeWaitForMultipleObjects can be running at IRQL <= DISPATCH_LEVEL. However, the caller cannot wait at raised IRQL for a nonzero interval nor in an arbitrary thread context on any dispatcher object. Therefore callers usually are running at IRQL = PASSIVE_LEVEL. A call while running at IRQL = DISPATCH_LEVEL is valid if and only if the caller specifies a Timeout of zero. That is, a driver must not wait for a nonzero interval at IRQL = DISPATCH_LEVEL.

KeWaitForSingleObject
The KeWaitForSingleObject routine puts the current thread into a wait state until the given dispatcher object is set to a signaled state or (optionally) until the wait times out.

NTSTATUS
  KeWaitForSingleObject(
    IN PVOID  Object,
    IN KWAIT_REASON  WaitReason,
    IN KPROCESSOR_MODE  WaitMode,
    IN BOOLEAN  Alertable,
    IN PLARGE_INTEGER  Timeout  OPTIONAL
    );
Parameters
Object
Pointer to an initialized dispatcher object (event, mutex, semaphore, thead, or timer) for which the caller supplies the storage.
WaitReason
Specifies the reason for the wait. A driver should set this value to Executive, unless it is doing work on behalf of a user and is running in the context of a user thread, in which case it should set this value to UserRequest.
WaitMode
Specifies whether the caller waits in KernelMode or UserMode. Lowest-level and intermediate drivers should specify KernelMode. If the given Object is a mutex, the caller must specify KernelMode.
Alertable
Specifies a Boolean value that is TRUE if the wait is alertable and FALSE otherwise.
Timeout
Pointer to a time-out value that specifies the absolute or relative time at which the wait is to be completed (optional). A negative value specifies an interval relative to the current time. The value should be expressed in units of 100 nanoseconds. Absolute expiration times track any changes in the system time; relative expiration times are not affected by system time changes.
Return Value
KeWaitForSingleObject can return one of the following:

STATUS_SUCCESS
The dispatcher object specified by the Object parameter satisfied the wait.
STATUS_ALERTED
The wait was completed because of an alert to the thread.
STATUS_USER_APC
A user APC was delivered to the current thread before the specified Timeout interval expired.
STATUS_TIMEOUT
A time out occurred before the object was set to a signaled state. This value can be returned when the specified set of wait conditions cannot be immediately met and Timeout is set to zero.
Note that the NT_SUCCESS macro recognizes all of these status values as "success" values.

Headers
Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h.

Comments
The current state of the specified Object is examined to determine whether the wait can be satisfied immediately. If so, the necessary side effects are performed on the object. Otherwise, the current thread is put in a waiting state and a new thread is selected for execution on the current processor.

The Alertable parameter specifies whether the thread can be alerted and its wait state consequently aborted. If the value of this parameter is FALSE then the thread cannot be alerted, no matter what the value of the WaitMode parameter or the origin of the alert. The only exception to this rule is that of a terminating thread. Under certain circumstances a terminating thread can be alerted while it is in the process of winding down. A thread is automatically made alertable, for instance, when terminated by a user with a CTRL+C.

If the value of Alertable is TRUE and one of the following conditions is present, the thread will be alerted:

If the origin of the alert is an internal, undocumented kernel-mode routine used to alert threads.
The origin of the alert is a user-mode APC, and the value of the WaitMode parameter is UserMode.
In the first of these two cases, the thread’s wait is satisfied with a completion status of STATUS_ALERTED; in the second case, it is satisfied with a completion status of STATUS_USER_APC.

The thread must be alertable for a user-mode APC to be delivered. This is not the case for kernel-mode APCs. A kernel-mode APC can be delivered and executed even though the thread is not alerted. Once the APC's execution completes, the thread's wait resumes. A thread is never alerted, nor is its wait aborted, by the delivery of a kernel-mode APC.

The delivery of kernel-mode APCs to a waiting thread does not depend on whether the thread can be alerted. If the kernel-mode APC is a special kernel-mode APC, then the APC is delivered provided that IRQL < APC_LEVEL. If the kernel-mode APC is a normal kernel-mode APC, then the APC is delivered provided that the following three conditions hold: (1) IRQL < APC_LEVEL, (2) no kernel APC is in progress, and (3) the thread is not in a critical section.

A special consideration applies when the Object parameter passed to KeWaitForSingleObject is a mutex. If the dispatcher object waited on is a mutex, APC delivery is the same as for all other dispatcher objects during the wait. However, once KeWaitForSingleObject returns with STATUS_SUCCESS and the thread actually holds the mutex, only special kernel-mode APCs are delivered. Delivery of all other APCs, both kernel-mode and user-mode, is disabled. This restriction on the delivery of APCs persists until the mutex is released.

If the WaitMode parameter is UserMode, the kernel stack can be swapped out during the wait. Consequently, a caller must never attempt to pass parameters on the stack when calling KeWaitForSingleObject using the UserMode argument. If you allocate the event on the stack, you must set the WaitMode parameter to KernelMode.

It is especially important to check the return value of KeWaitForSingleObject when the WaitMode parameter is UserMode or Alertable is TRUE, because KeWaitForSingleObject might return early with a status of STATUS_USER_APC or STATUS_ALERTED.

All long term waits that can be aborted by a user should be UserMode waits and Alertable should be set to FALSE.

Where possible, Alertable should be set to FALSE and WaitMode should be set to KernelMode, in order to reduce driver complexity. The principal exception to this is when the wait is a long term wait.

For additional information, see Do Waiting Threads Receive Alerts and APCs?

If no Timeout is supplied, the calling thread remains in a wait state until the Object is signaled.

A Timeout of zero allows the testing of a set of wait conditions and for the conditional performance of any side effects if the wait can be immediately satisfied, as in the acquisition of a mutex.

Callers of KeWaitForSingleObject must be running at IRQL <= DISPATCH_LEVEL. Usually, the caller must be running at IRQL = PASSIVE_LEVEL and in a nonarbitrary thread context. A call while running at IRQL = DISPATCH_LEVEL is valid if and only if the caller specifies a Timeout of zero. That is, a driver must not wait for a nonzero interval at IRQL = DISPATCH_LEVEL.

KeWaitForMutexObject
The KeWaitForMutexObject routine puts the current thread into an alertable or nonalertable wait state until the given mutex object is set to a signaled state or (optionally) until the wait times out.

NTSTATUS
  KeWaitForMutexObject(
    IN PRKMUTEX  Mutex,
    IN KWAIT_REASON  WaitReason,
    IN KPROCESSOR_MODE  WaitMode,
    IN BOOLEAN  Alertable,
    IN PLARGE_INTEGER  Timeout  OPTIONAL
    );
Parameters
Mutex
Pointer to an initialized mutex object for which the caller supplies the storage.
WaitReason
Specifies the reason for the wait, which should be set to Executive. If the driver is doing work on behalf of a user and is running in the context of a user thread, this parameter should be set to UserRequest.
WaitMode
The caller must specify KernelMode.
Alertable
Specifies a Boolean value that indicates whether the wait is alertable.
Timeout
Pointer to a time-out value that specifies the absolute or relative time at which the wait is to be completed (optional). A negative value specifies an interval relative to the current time. The value should be expressed in units of 100 nanoseconds. Absolute expiration times track any changes in the system time; relative expiration times are not affected by system time changes.
Return Value
KeWaitForMutexObject can return one of the following:

STATUS_SUCCESS
The dispatcher object specified by the Mutex parameter satisfied the wait.
STATUS_ALERTED
The wait was completed because of an alert to the thread.
STATUS_USER_APC
A user APC was delivered to the current thread before the specified Timeout interval expired.
STATUS_TIMEOUT
A time out occurred before the mutex was set to a signaled state. This value can be returned when an explicit time-out value of zero is specified and the specified set of wait conditions cannot be immediately met.
Note that the NT_SUCCESS macro recognizes all of these status values as "success" values.

Headers
Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h.

Comments
KeWaitForMutexObject is a macro that converts to KeWaitForSingleObject, which can be used instead.

For better performance, use the ExXxxFastMutex routines instead of the KeXxxMutex routines. However, a fast mutex cannot be acquired recursively, as a kernel mutex can.

The current state of the given mutex object is examined to determine whether the wait can be satisfied immediately. If so, the necessary side effects are performed on the mutex. Otherwise, the current thread is put in a waiting state and a new thread is selected for execution on the current processor.

The Alertable parameter specifies whether the thread can be alerted and its wait state consequently aborted. If the value of this parameter is FALSE then the thread cannot be alerted, no matter what the value of the WaitMode parameter or the origin of the alert. The only exception to this rule is that of a terminating thread. A thread is automatically made alertable, for instance, when terminated by a user with a CTRL+C.

If the value of Alertable is TRUE and one of the following conditions is present, the thread will be alerted:

If the origin of the alert is an internal, undocumented kernel-mode routine used to alert threads.
The origin of the alert is a user-mode APC, and the value of the WaitMode parameter is UserMode.
In the first of these two cases, the thread’s wait is satisfied with a completion status of STATUS_ALERTED; in the second case, it is satisfied with a completion status of STATUS_USER_APC.

The thread must be alertable for a user-mode APC to be delivered. This is not the case for kernel-mode APCs. A kernel-mode APC can be delivered and executed even though the thread is not alerted. Once the APC's execution completes, the thread's wait resumes. A thread is never alerted, nor is its wait aborted, by the delivery of a kernel-mode APC.

The delivery of kernel-mode APCs to a waiting thread does not depend on whether the thread can be alerted. If the kernel-mode APC is a special kernel-mode APC, then the APC is delivered provided that IRQL < APC_LEVEL. If the kernel-mode APC is a normal kernel-mode APC, then the APC is delivered provided that the following three conditions hold: (1) IRQL < APC_LEVEL, (2) no kernel APC is in progress, and (3) the thread is not in a critical section.

Because KeWaitForMutexObject initiates a wait on a mutex object, a special consideration applies. APC delivery is the same for mutexes as for all other dispatcher objects during the wait to acquire the mutex. However, once KeWaitForMutexObject returns with STATUS_SUCCESS and the thread actually holds the mutex, only special kernel-mode APCs are delivered. Delivery of all other APCs, both kernel-mode and user-mode, is disabled. This restriction on the delivery of APCs persists until the mutex is released.

For additional information, see Do Waiting Threads Receive Alerts and APCs?

If the WaitMode parameter is UserMode, the kernel stack can be swapped out during the wait. Consequently, a caller must never attempt to pass parameters on the stack when calling KeWaitForMutexObject using the UserMode argument.

It is especially important to check the return value of KeWaitForMutexObject when the WaitMode parameter is UserMode or Alertable is TRUE, because KeWaitForMutexObject might return early with a status of STATUS_USER_APC or STATUS_ALERTED.

All long term waits that can be aborted by a user should be UserMode waits and Alertable should be set to FALSE.

Where possible, Alertable should be set to FALSE and WaitMode should be set to KernelMode, in order to reduce driver complexity. The principal exception to this is when the wait is a long term wait. If no Timeout is supplied, the calling thread remains in a wait state until the Mutex is signaled.

A Timeout of zero allows the testing of a set of wait conditions and for conditionally performing any side effects if the wait can be immediately satisfied, such as acquiring the Mutex.

Callers of KeWaitForMutexObject must be running at IRQL <= DISPATCH_LEVEL. Usually, the caller must be running at IRQL = PASSIVE_LEVEL and in a nonarbitrary thread context. A call while running at IRQL = DISPATCH_LEVEL is valid if and only if the caller specifies a Timeout of zero. That is, a driver must not wait for a nonzero interval at IRQL = DISPATCH_LEVEL.

谢了，够详细。