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.alt.net!usenet From: tony@ercolano.com (Anthony V. Ercolano) Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode Subject: Re: KeInsertQueueDpc bug on SMP systems? Date: Fri, 16 Jan 1998 21:36:59 GMT Organization: Altopia Corp. - Usenet Access - http://www.altopia.com Lines: 51 Message-ID: <34cfd06e.183398828@news.alt.net> References: <69lhm3$q2r$1@decius.ultra.net> <69od14$ptg@news.microsoft.com> Reply-To: tony@ercolano.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 Paul, I have a proposal for a doc change. Right now it says: "If the specified DPC object is already in the DPC queue, no operation is performed except to return FALSE. Otherwise, the DPC object is inserted in the DPC queue and a software interrupt is requested at IRQL DISPATCH_LEVEL on the current processor." after "return FALSE", please insert: "Or we may (if you're unlucky) totally screw up kernel maintained data structures, and bugcheck shortly thereafter. You can prevent our screwing up our own data structures by wrapping your code in a spinlock." Oh and by the way, I certainly didn't see any proposal in Jim's post about how dave should adjust his performance enhancement. What dave expects and what is PROMISED in the api are two different things. DPC's don't have to have anything to do with IO packets so that argument is spurious also. Dave is plain flat out wrong here. If he wanted different behavior he should have created new API. He shouldn't have changed old ones. You can do anything fast as long as you are willing to do it wrong. "Paul Sanders" wrote: >This thread worked its way to Dave Cutler. Someone asked me to post his >answer as I am somewhat active in the newsgroup. Here is his verbatim >response, > >From: David Cutler >Sent: Friday, January 16, 1998 10:52 AM >To: Darryl Havens >Subject: RE: From Newsgroup: Bug in KeInsertQueueDpc - Our investigation >seems to confirm this >I answered this before and told them - by design. We are aware of this and >we are not going to change the design. The reason it is the way it is is to >avoid a single lock and to have distributed dpcs that can be targeted. What >this mail proposes is a single lock that everyone would have to get behind >or another lock associated with th dpc object itself. >We don't expect that someone will try to to queue exactly the same dpc on >different processors simultaneously. We have never seen this problem before. >If someone tried to complete the same i/o packet simultaneously on two >different processors it will fail with horrible consequences as well. >We do not intend to do anything about this. They have found a solution in >their driver as described below by acquiring another spinlock before >attempting to insert their dpc. >d >