Maybe it’s worth to note that in Intel slang “thread” means a logical
CPU - like in “hyper-threading”.
In this sense, everything that runs on a logical CPU, even at DIRQL,
runs in a thread.
(Another example of confusing domain specific slang: Device Manager in
“big” Windows is a GUI applet that displays the device tree.
In WinCE, it is the process that hosts device drivers.)
Regards,
–pa
Alex Shvedov wrote:
>
Yep, APC_LEVEL is thread-specific, everything above is
processor-specifi, perhttp://msdn.microsoft.com/en-us/library/ms810029.aspx:.
> Processor-specific and Thread-specific IRQLs
> …
> The thread scheduler considers only thread priority, not IRQL, when
> preempting a thread. If a thread running at IRQL=APC_LEVEL blocks, the
> scheduler might select a new thread for the processor that was
> previously running at PASSIVE_LEVEL.
>
How does that contradict what I said? If a thread blocks, it’s not
ready to run, so it’s not a candidate. It hasn’t been pre-empted – it
blocked itself.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> How does that contradict what I said?
It does not, imho.
Someone - not you, iirc, it was Anton - noted that irql may have
thread affinity, ok, ok, be thread-specific, and I recalled that I saw
these two papers, “Locks…” and the one I quote.
Good papers, would not be surprised if DH is the author.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Thursday, June 25, 2009 1:16 PM
Subject: Re: [ntdev] How IRQL is reflected in hardware?
> Alex Shvedov wrote:
>>>
>> Yep, APC_LEVEL is thread-specific, everything above is
>> processor-specifi, per
>>
>> http://msdn.microsoft.com/en-us/library/ms810029.aspx:.
>>
>>
>> Processor-specific and Thread-specific IRQLs
>> …
>> The thread scheduler considers only thread priority, not IRQL, when
>> preempting a thread. If a thread running at IRQL=APC_LEVEL blocks, the
>> scheduler might select a new thread for the processor that was
>> previously running at PASSIVE_LEVEL.
>>
>
> How does that contradict what I said? If a thread blocks, it’s not
> ready to run, so it’s not a candidate. It hasn’t been pre-empted – it
> blocked itself.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> > The thread scheduler considers only thread priority, not IRQL
.> How does that contradict what I said?
Sorry, but it DOES contradict your statement (it is quoted below)
[begin quote]
A PASSIVE_LEVEL thread will not be scheduled as long as an APC_LEVEL thread is ready to run.
[end quote]
The quoted statement is simply wrong. If priority of a thread that runs at PASSIVE_LEVEL is above
that of the one that runs at APC_LEVEL and both are eligible for running, the former one will get scheduled first…
Anton Bassov
Assuming “DH” means Doron Holan, no he’s not the author. They were written
by Penny Orwick, who co-authored the Windows Driver Foundation book. I
provided a lot of the content, too.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Alex Shvedov” wrote in message news:xxxxx@ntdev…
>> How does that contradict what I said?
> It does not, imho.
>
> Someone - not you, iirc, it was Anton - noted that irql may have
> thread affinity, ok, ok, be thread-specific, and I recalled that I saw
> these two papers, “Locks…” and the one I quote.
>
> Good papers, would not be surprised if DH is the author.
>
>
>
> ----- Original Message -----
> From: “Tim Roberts”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, June 25, 2009 1:16 PM
> Subject: Re: [ntdev] How IRQL is reflected in hardware?
>
>
>> Alex Shvedov wrote:
>>>>
>>> Yep, APC_LEVEL is thread-specific, everything above is
>>> processor-specifi, per
>>>
>>> http://msdn.microsoft.com/en-us/library/ms810029.aspx:.
>>>
>>>
>>> Processor-specific and Thread-specific IRQLs
>>> …
>>> The thread scheduler considers only thread priority, not IRQL, when
>>> preempting a thread. If a thread running at IRQL=APC_LEVEL blocks, the
>>> scheduler might select a new thread for the processor that was
>>> previously running at PASSIVE_LEVEL.
>>>
>>
>> How does that contradict what I said? If a thread blocks, it’s not
>> ready to run, so it’s not a candidate. It hasn’t been pre-empted – it
>> blocked itself.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> Assuming “DH” means Doron Holan, no he’s not the author. They were
written by Penny Orwick, who co-authored the Windows Driver Foundation
book. I provided a lot of the content, too.
Ok then, here is my personal special “thank you” to all three of you for
your
writtten work.
Tim: >.> How does that contradict what I said?
Anton: > Sorry, but it DOES contradict your statement (it is quoted below)
[begin quote]
A PASSIVE_LEVEL thread will not be scheduled as long as an APC_LEVEL
thread is ready to run.
[end quote]
Hmmm, it looks like Tim (and myself) were wrong, the MSDN article I quoted
says, in the first place, that “The thread scheduler considers only thread
priority,
not IRQL, when preempting a thread.” The example of blocked APC in the next
sentence is just that, an example.
If thread scheduler ignores IRQL, then the principle is very simple: is
scheduler
allowed to run? ( = is the processor < dispatch?)
If yes, then look at priorities of threads that are ready to run, period
(IRQL? who
said IRQL? what is it?)
----- Original Message -----
From: “Jake Oshins”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, June 25, 2009 3:24 PM
Subject: Re:[ntdev] How IRQL is reflected in hardware?
> Assuming “DH” means Doron Holan, no he’s not the author. They were
> written by Penny Orwick, who co-authored the Windows Driver Foundation
> book. I provided a lot of the content, too.
>
> –
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Group
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------------------------
>
>
> “Alex Shvedov” wrote in message news:xxxxx@ntdev…
>>> How does that contradict what I said?
>> It does not, imho.
>>
>> Someone - not you, iirc, it was Anton - noted that irql may have
>> thread affinity, ok, ok, be thread-specific, and I recalled that I saw
>> these two papers, “Locks…” and the one I quote.
>>
>> Good papers, would not be surprised if DH is the author.
>>
>>
>>
>> ----- Original Message -----
>> From: “Tim Roberts”
>> To: “Windows System Software Devs Interest List”
>> Sent: Thursday, June 25, 2009 1:16 PM
>> Subject: Re: [ntdev] How IRQL is reflected in hardware?
>>
>>
>>> Alex Shvedov wrote:
>>>>>
>>>> Yep, APC_LEVEL is thread-specific, everything above is
>>>> processor-specifi, per
>>>>
>>>> http://msdn.microsoft.com/en-us/library/ms810029.aspx:.
>>>>
>>>>
>>>> Processor-specific and Thread-specific IRQLs
>>>> …
>>>> The thread scheduler considers only thread priority, not IRQL, when
>>>> preempting a thread. If a thread running at IRQL=APC_LEVEL blocks, the
>>>> scheduler might select a new thread for the processor that was
>>>> previously running at PASSIVE_LEVEL.
>>>>
>>>
>>> How does that contradict what I said? If a thread blocks, it’s not
>>> ready to run, so it’s not a candidate. It hasn’t been pre-empted – it
>>> blocked itself.
>>>
>>> –
>>> Tim Roberts, xxxxx@probo.com
>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer