From - Mon Sep 15 09:07:32 1997
Path: news.mitre.org!blanket.mitre.org!news.tufts.edu!cam-news-feed5.bbnplanet.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed1-hme1!newsfeed.internetmci.com!205.139.102.6!news.fta.com!not-for-mail
From: billa@jetdrivers.com (bill a)
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: cancelable IRP's
Date: Fri, 12 Sep 1997 21:01:56 GMT
Organization: Internet Partners, Inc.
Lines: 18
Message-ID: <5vcabq$olo$1@news.fta.com>
References: <3407B5C0.4AC4@dial.pipex.com> <1997Aug29.160926.8113@cmkrnl>
NNTP-Posting-Host: 206.98.124.130
X-Newsreader: Forte Free Agent 1.0.82

jeh@cmkrnl.com (Jamie Hanrahan) wrote:

}condition there, no matter how clever the driver is).  For 
}driver-managed IRPs, briefly, the key is to protect the data that
keeps 
}track of your IRP (such as a doubly-linked list) with a spinlock, and

}acquire this spinlock in both your cancel and other driver routines, 
}so that no two of them can ever pull the same IRP off of the list. 
}I'll try to write more on this soon. 

One further point to make about using additional spinlocks in the
cancel routine is everywhere else that spinlock is used, you should
grab the cancel spinlock before grabbing your own and of course
release in reverse. Ie, your magic spinlock itself has to be protected
by the cancel spinlock.


From - Mon Sep 15 09:08:17 1997
Path: news.mitre.org!blanket.mitre.org!agate!newsgate.duke.edu!nntprelay.mathworks.com!europa.clark.net!205.252.116.205!howland.erols.net!usc!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: cancelable IRP's
Message-ID: <1997Sep13.003954.8169@cmkrnl>
Date: 13 Sep 97 00:39:54 PST
References: <3407B5C0.4AC4@dial.pipex.com> <1997Aug29.160926.8113@cmkrnl> <5vcabq$olo$1@news.fta.com>
Organization: Kernel Mode Systems, San Diego, CA
Lines: 44


In article <5vcabq$olo$1@news.fta.com>, billa@jetdrivers.com (bill a) writes:
> jeh@cmkrnl.com (Jamie Hanrahan) wrote:
> 
> }condition there, no matter how clever the driver is).  For 
> }driver-managed IRPs, briefly, the key is to protect the data that
> keeps 
> }track of your IRP (such as a doubly-linked list) with a spinlock, and
> 
> }acquire this spinlock in both your cancel and other driver routines, 
> }so that no two of them can ever pull the same IRP off of the list. 
> }I'll try to write more on this soon. 
> 
> One further point to make about using additional spinlocks in the
> cancel routine is everywhere else that spinlock is used, you should
> grab the cancel spinlock before grabbing your own and of course
> release in reverse. Ie, your magic spinlock itself has to be protected
> by the cancel spinlock.

Um, actually, no, this isn't necessary, on several different levels.
All that matters is that all code paths that DO acquire multiple
spinlocks out of a set acquire them in the same sequence -- but it is
not required that all code paths acquire the entire set.  

And release order (within a single IRQL, anyway) is immaterial.  I 
realize that this sounds counterintuitive to some, but if you disagree 
with this statement, try coming up with a scenario where different 
release sequences causes problems.  

More specifically to the cancel spinlock:  If you abandon
IoStart[Next]Packet and operate your own queues, it is possible to
drop the cancel spinlock very early in the cancel routine, prior to
acquiring your IRP queue spinlock -- thereby avoiding nested
acquisition entirely, and minimizing the acquisitions of the cancel 
spinlock in other parts of the driver.  

I really am trying to get an article on all this finished, but I'm 
trying to do several other things too... 

	--- 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.