Kernel Mustard

If you own a driver that makes assumptions about what processor you’re executing on at any point, you may want to re-think that strategy.

It has been possible in the past to assume that, if you’re running at DISPATCH_LEVEL on a given physical processor, you can get away with less locking if you do per-processor data structures. It makes sense: you are guaranteed to be the only thread in your code on that CPU until you’re done, since you can only be preempted by threads > DISPATCH_LEVEL, and your DPC will pick up where it left off once the system returns to DISPATCH_LEVEL. With a per-processor queue or other data structure, accesses from DISPATCH_LEVEL are guaranteed to be atomic.

Well, for reasons that will become clear over the next few months, that strategy is no longer possible. There may be cases in future versions of Windows that allow different physical processors to be assigned the same processor ID. That means that two different threads running at the same time on different processors might wind up colliding on the same queue.

Of course, this also implies that data structures that were once assumed to be per-processor exclusive (i.e. singletons) will no longer necessarily be so. If you’re using processor number as a key that you assume is globally unique, e.g. managing some initialize-once data or something, you will need to re-think your architecture.

If you don’t generally deal with processor numbers, none of this matters to you. For those that do, however, if you do anything "smart" with processor numbers, you may have some re-thinking to do.

Ken, Soren, and I are at DDC 2008 this week. So far, the talks have been great, as is the weather. If you’re around, drop one of us a line.

-Steve