Path: news.mitre.org!blanket.mitre.org!nntprelay.mathworks.com!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: Thu, 22 Jan 1998 20:29:58 GMT Organization: Altopia Corp. - Usenet Access - http://www.altopia.com Lines: 108 Message-ID: <34c7a559.19655531@news.alt.net> References: <69lhm3$q2r$1@decius.ultra.net> <69od14$ptg@news.microsoft.com> <34cfd06e.183398828@news.alt.net> 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 johns@chiark.greenend.org.uk (John Sullivan) wrote: >In article <34cfd06e.183398828@news.alt.net>, >Anthony V. Ercolano wrote: >>Paul, I have a proposal for a doc change. > >I think you're missing the point a little and being overly >inflammatory about this. No I'm not missing the point. I am acting upset. I did apologize to Paul privately (I've known and worked with Paul for many years.) > >>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. > >The IRP 'argument' was actually just another example of things that >can (and will) go wrong if *you* the programmer are not careful. This has NOTHING to do with the programmer being careful. This has to do with the fact that Dave changed the underlying semantics of a KE api between NT 3.1 and NT 3.5. Period. > >My interpretation of the KeInsertQueueDpc call is that a single DPC >object may be queued only once. Re-queueing the same object is >expected to be a no-op returning FALSE, however this does not (to me!) >indicate that you are expected to actually try to re-queue the same >DPC twice. Your interpretation of the API is is defficient. You are of course expected to be able to queue the DPC MORE THAN ONCE. This is how it is designed. It is expected that an ISR can and will call insertqueue with the same dpc. It is very possible and the driver writer must deal with the fact that the ISR might be reinvoked before the DPC queue is emptied. The underlying inability to pass much context information to DPC's is a central idea that driver writers have to deal with. I have been dealing with this API since 1990. I had Daves original KE design documentation on my desk for the next 7 years. I absolutely know how it was originally designed. Call the NT serial driver overly engineered, but it uses more DPC's then just about anything else in the system. > >This is after all not user mode, so the system can not physically (and Yes I am aware of the difference between user mode and kernel mode. If you are on an NT machine, you are using my kernel mode code in one way another. If you use a modem with NT you are using both my kernel and user mode code. >shouldn't) protect us from the results of all invalid operations, or >even some that we might quite like. This is just one case where the >kernel is making an assumption about the use of its objects, and if This API is quite simple. Making an assumption about its use is irrelevant. Its existance as KE api makes it pretty plain what it should be able to do and WAS able to do in 3.1 >you want to push things I don't see a problem with having to implement >an extra lock yourself. I'd much rather see the documentation updated John, point me to ANY other kernel KE api where you have to protect the integrity of the kernels data structures with you own MP safe mutual exclusion techniques. I really don't think you can. What was an underlying design principle is that the kernel WOULD provide you with correctly implemented MP safe operations that a kernel mode developer might need to use. This was done precisely because it is hard for even very good engineers to get these things done correctly. Are you saying that I can't call KeSetEvent with the same event on 2 different processors at the same time? Are you saying that I can't call KeSetTimer withthe same timer on 2 different processors at the same time? >to make this clear, than introduce the extra overhead across the board >even for callers who are careful about when they queue >DPCs. Efficiency concerns *are* more important in kernel mode. I am aware of efficiency concerns. I am also aware that kernel API's are supposed to be MP safe. This WAS a design goal from day 1. > >>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. > >Changed? From what? I see only a single function that appears to do, >and to have done, what it was designed to do. The documentation may be >slightly misleading but... The MP safety of this api changed from 3.1 to 3.5. > >John John, I do appreciate your comments. Thank you for taking the time to make them. - tony ps - I'm pretty much done with this topic. I've lost too much sleep over it already.