If a thread is running at APC_LEVEL (either by using a lock or by manually
raising to APC_LEVEL), an interrupt or DPC can preempt the thread.
But is it possible another thread gets scheduled on that processor before
the IRQL of the APC level thread has dropped to PASSIVE_LEVEL ?
Based on the rules of IRQLs I would suppose not, but since these are special
case software interrupts I would not mind to get a confirmation.
//Daniel
Yes. (Otherwise, you would not be able to wait at APC_LEVEL.)
From: xxxxx@resplendence.commailto:xxxxx
Sent: ?2/?22/?2013 2:31
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] doubt about APC_LEVEL
If a thread is running at APC_LEVEL (either by using a lock or by manually
raising to APC_LEVEL), an interrupt or DPC can preempt the thread.
But is it possible another thread gets scheduled on that processor before
the IRQL of the APC level thread has dropped to PASSIVE_LEVEL ?
Based on the rules of IRQLs I would suppose not, but since these are special
case software interrupts I would not mind to get a confirmation.
//Daniel
—
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
> Based on the rules of IRQLs I would suppose not, but since these are special case software
interrupts I would not mind to get a confirmation.
Well, by means of IRQL Windows manipulates two totally different concepts that are known under other OSes as respectively signal delivery and atomic context. IRQL APC_LEVEL disables APC (i.e. signal) delivery. If thread goes into the blocking state at this IRQL it will not be awoken by APC delivery even it it specifies ‘Alertable’ parameter as TRUE. This IRQL works on the basis of thread, rather than CPU, and, hence, does not disable a dispatcher. It is normally used to indicate that the thread in question may hold some dispatcher-level synch construct that cannot be acquired recursively.
Any IRQL above it is already known as an “atomic context” under other OSes. It means that the currently running unit of execution either does not have its own stack (i.e. CPU executes interrupt or DPC handler), and, hence, is not in a position to make a blocking call, or currently running code synchronizes with such a unit of execution (i.e. owns a spinlock). This notion applies already on the basis of CPU, rather than thread, and disables a dispatcher.
By convention, the term “elevated IRQL” that is used in documentation seems to refer only to
IRQL> APC_LEVEL, which is the source of endless confusion…
Anton Bassov