This may have been answered before, but what IRQL do System Threads run at?
Does raising the priority affect that? Thanks.
Per the documentation:
“Threads, whatever their respective run-time priorities, are run at IRQL
PASSIVE_LEVEL.”
Note that they’re talking about threads created by drivers using routines
like PsCreateSystemThread, IoAllocateWorkItem/IoQueueWorkItem, and
FltAllocateDeferredIoWorkItem/FltQueueDeferredIoWorkItem.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 5:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run at?
Does raising the priority affect that? Thanks.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
PASSIVE_LEVEL
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run at?
Does raising the priority affect that? Thanks.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
__________ NOD32 1.1196 (20050817) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
System threads *run* at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any *driver* code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not *quite*
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> For example, they are not prohibited from acquiring
spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
>any *driver* code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not *quite*
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL).
Hmm… why does the documentation say KeDelayExecutionThread is callable
at <= APC_LEVEL ?
No, system threads are created by calling PsCreateSystemThread. I
believe you are confusing a “system thread” with a “work queue thread”.
The Executive creates a pool of system threads for servicing work items
that are inserted into the work queues; the ExQueueWorkItem function is
traditionally used, although the current preference is that you use
IoQueueWorkItem. But when discussing the executive worker threads, work
items should leave the thread state comparable to what it was on entry.
With that said, in my experience, it is not safe for file system filter
drivers to use system work queues. I generally build my own even in a
file system because I find the high priority assigned to the executive
work queues does not provide me with the background style processing I
am seeking. In a filter driver, I’ve had far too many deadlock issues
between my filter and the underlying file system using the same work
queue - best to avoid them entirely by using a different work queue.
Notice that filter manager has its own work queues as well.
So perhaps the OP was asking “at what IRQL level will work items that I
post to system work queues be called”, to which the answer should always
be: “IRQL PASSIVE_LEVEL”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
Sent: Friday, August 19, 2005 12:05 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
For example, they are not prohibited from acquiring
spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Why so it does! I must either be mis-remembering things or this has
changed (either of which is certainly possible). Now I’ll have to dig
out one of my old DDKs and make sure I’m not losing my mind.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 12:16 PM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
any *driver* code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not *quite*
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL).
Hmm… why does the documentation say KeDelayExecutionThread is callable
at <= APC_LEVEL ?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Tony:
So, assuming all other things are equal (i.e., running at PASSIVE_LEVEL), is
it correct to assume that a user-mode program running at priority 4 will get
scheduled before a system thread running at priority 3?
This is the crux of my original (related) question.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, August 19, 2005 12:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] System Threads and IRQ Levels
No, system threads are created by calling PsCreateSystemThread. I
believe you are confusing a “system thread” with a “work queue thread”.
The Executive creates a pool of system threads for servicing work items
that are inserted into the work queues; the ExQueueWorkItem function is
traditionally used, although the current preference is that you use
IoQueueWorkItem. But when discussing the executive worker threads, work
items should leave the thread state comparable to what it was on entry.
With that said, in my experience, it is not safe for file system filter
drivers to use system work queues. I generally build my own even in a
file system because I find the high priority assigned to the executive
work queues does not provide me with the background style processing I
am seeking. In a filter driver, I’ve had far too many deadlock issues
between my filter and the underlying file system using the same work
queue - best to avoid them entirely by using a different work queue.
Notice that filter manager has its own work queues as well.
So perhaps the OP was asking “at what IRQL level will work items that I
post to system work queues be called”, to which the answer should always
be: “IRQL PASSIVE_LEVEL”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
Sent: Friday, August 19, 2005 12:05 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
For example, they are not prohibited from acquiring
spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> I believe you are confusing a “system thread” with a “work queue thread”.
Oops! I did, sorry.
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 12:38 PM
Subject: RE: [ntfsd] System Threads and IRQ Levels
No, system threads are created by calling PsCreateSystemThread. I
believe you are confusing a “system thread” with a “work queue thread”.
The Executive creates a pool of system threads for servicing work items
that are inserted into the work queues; the ExQueueWorkItem function is
traditionally used, although the current preference is that you use
IoQueueWorkItem. But when discussing the executive worker threads, work
items should leave the thread state comparable to what it was on entry.
With that said, in my experience, it is not safe for file system filter
drivers to use system work queues. I generally build my own even in a
file system because I find the high priority assigned to the executive
work queues does not provide me with the background style processing I
am seeking. In a filter driver, I’ve had far too many deadlock issues
between my filter and the underlying file system using the same work
queue - best to avoid them entirely by using a different work queue.
Notice that filter manager has its own work queues as well.
So perhaps the OP was asking “at what IRQL level will work items that I
post to system work queues be called”, to which the answer should always
be: “IRQL PASSIVE_LEVEL”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
Sent: Friday, August 19, 2005 12:05 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
> For example, they are not prohibited from acquiring
> spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ken,
Basically, yes. Thread scheduling is done entirely inside the micro
kernel and as far as it is concerned, the two different types of threads
are indistinguishable (they both have KTHREAD structures, which is all
it cares about…)
Of course I said basically because on an MP (or SMT/Hyperthread or
dual-core) system those threads could both be running, albeit on
different processors. Further, you will occasionally see situations
where a higher priority thread is in standby (ready to run) but a lower
priority thread is running on the processor. Presumably, this is
because in general it is more efficient to let the lower priority thread
keep running versus sending an IPI to the other processor telling it to
switch to the higher priority thread.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Friday, August 19, 2005 12:53 PM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
Tony:
So, assuming all other things are equal (i.e., running at
PASSIVE_LEVEL), is
it correct to assume that a user-mode program running at priority 4 will
get
scheduled before a system thread running at priority 3?
This is the crux of my original (related) question.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, August 19, 2005 12:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] System Threads and IRQ Levels
No, system threads are created by calling PsCreateSystemThread. I
believe you are confusing a “system thread” with a “work queue thread”.
The Executive creates a pool of system threads for servicing work items
that are inserted into the work queues; the ExQueueWorkItem function is
traditionally used, although the current preference is that you use
IoQueueWorkItem. But when discussing the executive worker threads, work
items should leave the thread state comparable to what it was on entry.
With that said, in my experience, it is not safe for file system filter
drivers to use system work queues. I generally build my own even in a
file system because I find the high priority assigned to the executive
work queues does not provide me with the background style processing I
am seeking. In a filter driver, I’ve had far too many deadlock issues
between my filter and the underlying file system using the same work
queue - best to avoid them entirely by using a different work queue.
Notice that filter manager has its own work queues as well.
So perhaps the OP was asking “at what IRQL level will work items that I
post to system work queues be called”, to which the answer should always
be: “IRQL PASSIVE_LEVEL”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
Sent: Friday, August 19, 2005 12:05 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
For example, they are not prohibited from acquiring
spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Tony,
Thanks for the lowdown. So you are saying that it is better to use a System
Thread (PsCreateSystemThread) rather than a Work Item (ExQueueWorkItem) in a
filter driver? I use both at different times but have not run into any
problems with Work Items. Maybe I have been lucky so far?
Incidentally, I think I found another subtle difference between System
Threads and Work Items. When calling a WI from a dispatch routine, the WI
seems to obey the cpu affinity of the invoking process. So that if the
process is limited to a single cpu, the WI will only run on that cpu. A ST
does not seem to have that limitation.
Neil
On a related note - how do I change the priority of a system thread? I have
used the following code, but always get a bugcheck. This is the stripped
down code:
PsCreateSystemThread(
&ThreadHandle,
0,
NULL,
NULL,
NULL,
ProcessSystemThread,
context);
KeSetPriorityThread(
ThreadHandle,
LOW_REALTIME_PRIORITY);
Thanks for any tips.
Neil
I use ZwSetinformationThread and I have the thread set
its own priority at the beginning of its entry
routine.
— Neil Weicher wrote:
> On a related note - how do I change the priority of
> a system thread? I have
> used the following code, but always get a bugcheck.
> This is the stripped
> down code:
>
> PsCreateSystemThread(
> &ThreadHandle,
> 0,
> NULL,
> NULL,
> NULL,
> ProcessSystemThread,
> context);
> KeSetPriorityThread(
> ThreadHandle,
> LOW_REALTIME_PRIORITY);
>
> Thanks for any tips.
>
> Neil
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
The Windows OS doesn’t have a micro-kernel.
–
James Antognini
Windows DDK and WDK Support
This posting is provided “AS IS” with no warranties, and confers no rights.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Ken,
Basically, yes. Thread scheduling is done entirely inside the micro
kernel and as far as it is concerned, the two different types of threads
are indistinguishable (they both have KTHREAD structures, which is all
it cares about…)
Of course I said basically because on an MP (or SMT/Hyperthread or
dual-core) system those threads could both be running, albeit on
different processors. Further, you will occasionally see situations
where a higher priority thread is in standby (ready to run) but a lower
priority thread is running on the processor. Presumably, this is
because in general it is more efficient to let the lower priority thread
keep running versus sending an IPI to the other processor telling it to
switch to the higher priority thread.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Friday, August 19, 2005 12:53 PM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
Tony:
So, assuming all other things are equal (i.e., running at
PASSIVE_LEVEL), is
it correct to assume that a user-mode program running at priority 4 will
get
scheduled before a system thread running at priority 3?
This is the crux of my original (related) question.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, August 19, 2005 12:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] System Threads and IRQ Levels
No, system threads are created by calling PsCreateSystemThread. I
believe you are confusing a “system thread” with a “work queue thread”.
The Executive creates a pool of system threads for servicing work items
that are inserted into the work queues; the ExQueueWorkItem function is
traditionally used, although the current preference is that you use
IoQueueWorkItem. But when discussing the executive worker threads, work
items should leave the thread state comparable to what it was on entry.
With that said, in my experience, it is not safe for file system filter
drivers to use system work queues. I generally build my own even in a
file system because I find the high priority assigned to the executive
work queues does not provide me with the background style processing I
am seeking. In a filter driver, I’ve had far too many deadlock issues
between my filter and the underlying file system using the same work
queue - best to avoid them entirely by using a different work queue.
Notice that filter manager has its own work queues as well.
So perhaps the OP was asking “at what IRQL level will work items that I
post to system work queues be called”, to which the answer should always
be: “IRQL PASSIVE_LEVEL”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
Sent: Friday, August 19, 2005 12:05 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
> For example, they are not prohibited from acquiring
> spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Head on over to building 26 and tell that to Cutler… 
While Microsoft doesn’t distribute a separate binary image that is
called the “micro-kernel” the structure of the OS was geared towards
that model, and even today the kernel components are structurally
separable - providing services to the OS executive through a small set
of core services. The only piece with which this breaks down is in
areas that are highly machine specific (read: virtual memory).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Antognini
[MSFT]
Sent: Friday, August 19, 2005 2:01 PM
To: ntfsd redirect
Subject: Re:[ntfsd] System Threads and IRQ Levels
The Windows OS doesn’t have a micro-kernel.
–
James Antognini
Windows DDK and WDK Support
This posting is provided “AS IS” with no warranties, and confers no
rights.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Ken,
Basically, yes. Thread scheduling is done entirely inside the micro
kernel and as far as it is concerned, the two different types of threads
are indistinguishable (they both have KTHREAD structures, which is all
it cares about…)
Of course I said basically because on an MP (or SMT/Hyperthread or
dual-core) system those threads could both be running, albeit on
different processors. Further, you will occasionally see situations
where a higher priority thread is in standby (ready to run) but a lower
priority thread is running on the processor. Presumably, this is
because in general it is more efficient to let the lower priority thread
keep running versus sending an IPI to the other processor telling it to
switch to the higher priority thread.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Friday, August 19, 2005 12:53 PM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
Tony:
So, assuming all other things are equal (i.e., running at
PASSIVE_LEVEL), is
it correct to assume that a user-mode program running at priority 4 will
get
scheduled before a system thread running at priority 3?
This is the crux of my original (related) question.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, August 19, 2005 12:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] System Threads and IRQ Levels
No, system threads are created by calling PsCreateSystemThread. I
believe you are confusing a “system thread” with a “work queue thread”.
The Executive creates a pool of system threads for servicing work items
that are inserted into the work queues; the ExQueueWorkItem function is
traditionally used, although the current preference is that you use
IoQueueWorkItem. But when discussing the executive worker threads, work
items should leave the thread state comparable to what it was on entry.
With that said, in my experience, it is not safe for file system filter
drivers to use system work queues. I generally build my own even in a
file system because I find the high priority assigned to the executive
work queues does not provide me with the background style processing I
am seeking. In a filter driver, I’ve had far too many deadlock issues
between my filter and the underlying file system using the same work
queue - best to avoid them entirely by using a different work queue.
Notice that filter manager has its own work queues as well.
So perhaps the OP was asking “at what IRQL level will work items that I
post to system work queues be called”, to which the answer should always
be: “IRQL PASSIVE_LEVEL”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
Sent: Friday, August 19, 2005 12:05 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
> For example, they are not prohibited from acquiring
> spin locks (and raising IRQL to DISPATCH_LEVEL)
Correct me if I’m wrong, but I thought that system threads
are in a pool. Think about a horse stable where you
can rent a horse for some time and then return it so that
someone else has the next ride.
Now, what if I LEAVE the horse on an elevated level
after I’m done?
The next rider might not expect that - work items are
supposed to run at PASSIVE, and they are run by
threads from a system pool.
Can it be said then that yes, your code that runs in a
system pool is allowed to elevate the IRQL, but only
temporarily?
Meaning “clean your horse before returning it back to
the stable”.
Is this a correct picture?
[Alternatively, someone does it before allowing the next
rider in (which I think does not happen).]
Regards,
Alex Shvedov
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 19, 2005 11:16 AM
Subject: RE: [ntfsd] System Threads and IRQ Levels
System threads run at any IRQL. For example, they are not prohibited
from acquiring spin locks (and raising IRQL to DISPATCH_LEVEL) or
acquiring fast mutexes (and raising IRQL to APC_LEVEL). They can even
call ISR synchronize routines (and raise to DIRQL).
The implicit question (and seemingly the answers) seems to be “at what
IRQL do system threads START executing?” The answer to THAT is:
PASSIVE_LEVEL. From a driver perspective, code executing in a user
thread versus one executing in a system thread is generally identical.
Scheduling has to do with the management of thread priorities as they
use the processor; the scheduler runs at IRQL DISPATCH_LEVEL and thus
any driver code (regardless of thread context) that raises IRQL to
DISPATCH_LEVEL is non-preemptable (but, oddly enough, not quite
non-dispatchable - check out KeDelayExecutionThread which does work at
DISPATCH_LEVEL). Scheduling, while conceptually simple is fiendishly
complicated in application because it is (from a computational
complexity perspective) a “hard problem” (well, perfect scheduling is a
“hard problem”). Thus scheduling priority only comes into play when a
thread is running at IRQL < DISPATCH_LEVEL (e.g., PASSIVE_LEVEL or
APC_LEVEL).
And, just as a side-note, the IDLE thread is not scheduled it is
“chosen” because there are no schedulable threads to run. It actually
executes at DISPATCH_LEVEL.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, August 19, 2005 10:58 AM
To: ntfsd redirect
Subject: RE: [ntfsd] System Threads and IRQ Levels
PASSIVE_LEVEL.
No it does not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, August 18, 2005 2:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] System Threads and IRQ Levels
This may have been answered before, but what IRQL do System Threads run
at?
Does raising the priority affect that? Thanks.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
That crashes because you are passing a handle into a routine that
requires a thread object. You could do it via the Zw API or you could
obtain the thread object pointer and pass that into KeSetPriorityThread.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Friday, August 19, 2005 1:46 PM
To: ntfsd redirect
Subject: Re: [ntfsd] System Threads and IRQ Levels
On a related note - how do I change the priority of a system thread? I
have
used the following code, but always get a bugcheck. This is the stripped
down code:
PsCreateSystemThread(
&ThreadHandle,
0,
NULL,
NULL,
NULL,
ProcessSystemThread,
context);
KeSetPriorityThread(
ThreadHandle,
LOW_REALTIME_PRIORITY);
Thanks for any tips.
Neil
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Really ?? You are taking what Tony is saying too literally. From MSDN
“The Windows NT operating system is based on a design principle often
referred to as a microkernel architecture”
My win2k ddk docs seem to be saying KeDelayExecutionThread can be used
only at PASSIVE_LEVEL.