Path: news.mitre.org!blanket.mitre.org!philabs!newsjunkie.ans.net!newsfeeds.ans.net!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-peer.sprintlink.net!news-backup-west.sprintlink.net!news-in-west.sprintlink.net!news.sprintlink.net!Sprint!209.90.0.8!alpha.sky.net!newshub.cts.com!newsfeed.cts.com!cmkrnl!jeh From: jeh@cmkrnl.com (Jamie Hanrahan) Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode Subject: Re: Synchronization of driver routines w/spinlock Message-ID: <1998Jan14.185110.8411@cmkrnl> Date: 14 Jan 98 18:51:10 PST References: <693kh2$f55$1@Radon.Stanford.EDU> <34ba0edf.2602462@spock> Organization: Kernel Mode Systems, San Diego, CA Lines: 89 In article , sihde@Xenon.Stanford.EDU (Steve Ihde) writes: >>>>>2. A routine running at some IRQL cannot be interrupted by any other >>>>>routine that would be running on the same or a lower IRQL *on the same >>>>>processor*. However, *any* other routine *can* be running at the same >>>>>time (i.e. in parallel) on some other processor. > >>...and he's correct, for IRQLs >= DISPATCH_LEVEL. > > Does this mean, then, that there's no such thing as a software > interrupt at APC_LEVEL? No, it does not mean that. > Because if there is, it would seem that the > above statement would be true for APC_LEVEL as well. It is true for APC_LEVEL as long as you're in the same thread. However, a context switch CAN occur when you're at APC_LEVEL, and this could end up running another thread at APC_LEVEL or PASSIVE_LEVEL. Taking a step back and ignoring the causes of the context switch, it looks like one thread has "interrupted" another, with the "interrupting" thread being at an equal or even lower IRQL to the "interrupted" thread. (See why I don't like thinking of threads as "interrupting" other threads? :-) My point here is that being at any IRQL >= DISPATCH_LEVEL guarantees that NT won't call any other routine at your IRQL or below, on your CPU, until you return control to NT or lower IRQL. (Assuming of course that everyone plays by the rules, like never lowering IRQL below that at which your top-level routine was invoked.) And that the same is *not* true of APC_LEVEL -- unless you are thinking only of other routines within your current thread. > That is, that a routine running at APC_LEVEL couldn't be interrupted > by a software interrupt at APC_LEVEL or below, but that it could be > interrupted by a software interrupt at DISPATCH_LEVEL, which could run > the thread dispatcher and effect a context switch. > > You stated above that APC_LEVEL is a thread state, not a processor > state, but then why is it described as an IRQL? Is there an actual > software interrupt associated with this IRQL? It's an IRQL, and on the Alpha, which actually does have an IRQL field in the PSR, the IRQL field will be 1 when you're executing at APC_LEVEL. But I call it a thread state rather than a processor state because the fact that you're at PASSIVE_ vs. APC_LEVEL is saved and restored as part of the thread state -- I'm not sure of the exact representation in the KTHREAD object, but one way or another, this information is saved separately for each thread. And when you get back to a particular thread, the IRQL state of the processor is set to APC_LEVEL or PASSIVE_LEVEL according to that thread's saved context. That's what I mean by saying it's a state of each thread. While the thread is running, of course, the processor state reflects the thread's state... unless IRQL is raised above APC_LEVEL. Is that more clear? As for "actual software interrupts"... the whole concept of deferrable software interrupts at IRQLs below those of hardware interrupts is an abstraction on the x86 platforms anyway. (But it's real on the Alpha, and yes, there is an "IRQL 1" bit in the Alpha's Software Interrupt Request Register.) > BTW, I don't think the statement (2.) above is saying anything about > the conditions under which a thread can be context switched, only > about the conditions under which an interrupt (hardware or software) > can be serviced and its corresponding routine in the interrupt > dispatch table run. It seems to me to be making a statement about when you can lose control of the CPU to another routine running at the same or lower IRQL. Interpreted that way, the provision "for IRQL >= DISPATCH_LEVEL" clearly needs to be added. But that's as you prefer. My original post in this thread wasn't motivated by that statement at all, but rather by Mark Roddy's claim that context switching only happened at PASSIVE_LEVEL. I think we've all agreed that context switching can also happen to you when you're at APC_LEVEL. (And for anyone who doubts it, I suggest that you try it before posting a counter-claim... I did.) --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA Internet: jeh@cmkrnl.com (JH645) CompuServe: 74140,2055 drivers, internals, networks, applications, and training for VMS and Windows NT NT driver FAQ, links, and other information: http://www.cmkrnl.com/ If you post a reply in news, please don't e-mail it too.