Re: IRQL and thread priority
From: Peter Wieland [MSFT] (peterwie_at_online.microsoft.com)
Date: 06/08/04
- Next message: Maxim S. Shatskih: "Re: How do I know if a driver is installed successfuly?"
- Previous message: Krishna Monian: "Re: Detecting File Attributes in a filter driver"
- In reply to: Raj: "IRQL and thread priority"
- Next in thread: Maxim S. Shatskih: "Re: IRQL and thread priority"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 8 Jun 2004 08:42:06 -0700
(my glossary for today:
preempted = pulled off the processor so another thread can run.
interrupted = the thread is still on the processor, but is running a
higher-priority event like an APC, DPC or interrupt)
1) Threads are scheduled by priority regardless of whether they're in
user-mode or kernel-mode. So they can get preempted to run a
higher-priority thread, which could also be in your dispatch routine. As
long as the thread hasn't raised the IRQL level to DISPATCH_LEVEL or higher,
the thread can get preempted by the kernel.
2) Driver code running in an arbitrary thread at below DISPATCH_LEVEL is
still subject to the scheduler and runs with the priority of the thread it's
invoked in. But driver code usually runs in one of three places, and only
the last of those is truely arbitrary:
a - in a thread that is calling into the driver to service some I/O
request (or in an APC on a related thread)
b - in a worker thread allocated by the driver
c - in a DPC or ISR which interrupts an arbitrary thread.
Only code running at or above DPC level doesn't have to worry about getting
preempted by a higher-priority thread.
3) Nope. APCs are a way of interrupting a specific thread, but they don't
change the scheduling decisions made by the kernel. The next time the
thread runs it will first run the APC (or the next time it's in an alertable
wait, depending on the type of APC).
-p
-- This posting is provided "AS IS" with no warranties, and confers no rights. "Raj" <r_konjeti@mailcity.com> wrote in message news:8509fde8.0406080729.73392949@posting.google.com... > 1) Threads of different thread priorities call separate dispatch > routines of my driver using DeviceIoControl(). Does the dispatch > routine called by high priority thread executes "preempting" dispatch > routine code of lower priority thread. But all dispatch routines are > at PASSIVE_IRQL. Since these dispatch routines are runnning at thread > context, will they also get respective thread priority. > > 2) I know thread priorities are for scheduler only. But CPU has to > make decision of what code to service (whether influenced by scheduler > or not). Some driver code runs at arbitrary thread which means user > thread priorities dont affect those segments of driver code execution. > > 3) Is it code at APC_LEVEL and above is always prefered by CPU than > any high priority of user mode thread code. Even this may not be true > because MSDN is reluctant Applications using REAL_TIME_THREAD_PRIORITY > because that can effect file data flushing to disk etc. > > > Thanks.
- Next message: Maxim S. Shatskih: "Re: How do I know if a driver is installed successfuly?"
- Previous message: Krishna Monian: "Re: Detecting File Attributes in a filter driver"
- In reply to: Raj: "IRQL and thread priority"
- Next in thread: Maxim S. Shatskih: "Re: IRQL and thread priority"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
