Art,
What some people do is to have a book’s web site and an errata file in
there. A reference in the preface to the web site is enough, and after a few
interactions the readers learn fast where the errata is. For example, take a
look at http://www.cs.indiana.edu/eopl for the web page of Friedman, Wand
and Haynes’s book “Essentials of Programming Languages”, which I use in my
courses. Or you can look at http://theory.lcs.mit.edu for the web page of
Cormen, Leiserson and Rivest’s “Introduction to Algorithms”, which I also
use in my courses. The idea is to supplement the publishers’ mechanisms with
faster access to up to date information, including errata and programming
bugs. Works well in the academic world, I wonder if it would work out here
too.
Alberto.
-----Original Message-----
From: Art Baker [mailto:xxxxx@nfr.com]
Sent: Monday, September 24, 2001 4:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Deferred Procedure Call WindowsNT
Just to clarify something:
In point of fact, I corrected that error about multiprocessor DPCs in the
original galley proofs of the FIRST EDITION of the NT Driver Book – before
it ever went to press. Alas, the delightful production folks at Prentice
Hall never bothered to include my changes in the text of the book. On
successive printings, the error continued to appear.
I had planned on rewriting much of the book for its second edition.
Unfortunately, Prentice Hall and I couldn’t come to an agreement about a
schedule for the rewrite. (They were interested in “now” and I was pushing
for “correct.”) Exercising an ambiguous clause in the book contract, they
gave the job of preparing “The Windows 2000 Device Driver Book” to Mr.Lozano
and didn’t allow me to participate in any way whatsoever in the project.
(Indeed, to this day, I have never received so much as a piece of email from
Jeff Lozano.) So, once again, the necessary corrections didn’t happen.
In any event, my deepest apologies to those of you who have run into
problems because of this error.
The truth is that, yes indeed, multiple DPCs can run simultaneously on
multiprocessor boxes. So, be sure to use spinlocks or interlocked
instructions to guarantee the safety of any resources that might be shared
for write-access by those DPCs.
And now Little, Oney, Viscarola and Mason, Decker and Newcomer, AND Baker
are all saying the same thing… 
Regards,
Art Baker
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Monday, September 24, 2001 1:32 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Deferred Procedure Call WindowsNT
Yeah … and Little says the opposite of Baker/Lozano, as well. And that
comes from three years of getting screwed by multiple CPUs running the same
DPC, multiple times.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Marc Reinig [mailto:xxxxx@pacbell.net]
Sent: Monday, September 24, 2001 9:31 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Deferred Procedure Call WindowsNT
I got this from Baker/Lozano, “The Windows 2000 Device Driver Book”. Under
Behavior of DPC’s, in chapter 3 they say: “The DPC architecture prevents any
two DPCs from executing simultaneously, even on a multiprocessor machine.
Thus resources shared by different DPC routines do not need to worry about
synchronization.”
Haven’t reviewed the errata, can’t get to their site. However, on checking
Oney, Viscarola and Mason, and Decker and Newcomer, they all state the
opposite. So, in go the spinlocks ;=)
Thanks all,
Marc Reinig
System Solutions
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Evan Hillman
Sent: Monday, September 24, 2001 8:24 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Deferred Procedure Call WindowsNT
Marc,
I was burned by this one on my first driver. The hardware was quick to
generate interrupts, and I would at times (right off the bat, actually) get
a DPC running on each processor, merrily stepping all over each other.
I fixed it by simply re-enabling interrupts at the end of the DPC rather
than at the end of the ISR. While this worked fine for the driver, it
played havoc with the buggy PCI core we were using at the time. The poor
hardware guys were tearing their hair out for about two weeks.
As a side note: I am assembling a dual-processor system right now for the
very purpose of testing my drivers in a multi-processor environment. At
least one seminar teacher strongly recommends testing on a system with the
more-the-merrier number of CPUs.
And, as an added bonus, if your company is producing a multi-threaded
application as well, you may very well find some application bugs while you
are at it.
-Evan Hillman
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Marc Reinig
Sent: Sunday, September 23, 2001 11:55 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Deffered Procedure Call WindowsNT
Just for clarification, I thought that only one DPC would run on
a machine
at any time regardless of how many CPU’s it has (at least in Win2K). If
that is not the case, I need to rethink the synchronization in one of my
projects.
Marc Reinig
System Solutions
You are currently subscribed to ntdev as: xxxxx@pacbell.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@nfr.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com