Device Drivers and Processors

Windows NT and the XP support multiprocessor architecture. Windows platform holds conditions true as
1. All CPUs are identical and also they have no or identical co-processor.
2. All CPUs share memory or have access to the System memory.
3. Considering the sysmmetric platform, all CPUs take inturrupts, access memory or I/O Control registers.
Isn't this all good and makes easy for a programmer?
Windows NT and XP are designed to work on SMP platform. Similar to all other SMP operating systems Windows also take care that the driver sensitive data does not get modified by more than one processor at the same time.
The Spinlocks I wrote about yesterday, are used to preserve the same. For example, a lowest-level driver's ISR that is handling a device interrupt on one processor must have exclusive access to critical, driver-defined data (or the device registers) in case its device interrupts simultaneously on another processor. Understanding the SMP environment, I/O Requests are completed by one processor and device communications are executed by another processor, in this case, the driver critical data has to be shared with all the driver routines.
We cannot expect the any locking system without any policies. See what Microsoft says about this
1 .Only one routine can hold a particular spin lock at any given moment; only the holder of a spin lock can access the data it protects. Another routine must acquire the spin lock in order to access the same data, but the spin lock cannot be acquired until the current holder releases it.
2. Like a hardware or software interrupt vector, the Kernel assigns each spin lock in the system an associated IRQL value. A kernel-mode routine can acquire a particular spin lock only when the routine is run at the spin lock's assigned IRQL.

Microsoft does accept the fact that these policies prevent a driver routine that usually runs at a lower IRQL but is currently holding a spin lock from being preempted by a higher priority driver routine that is trying to acquire the same spin lock, thereby causing a deadlock.

DDK also says
A lowest-level driver's ISR frequently shares a state area with the driver's DPC routine, which calls a driver-supplied critical-section routine to access the shared area. In this case, the spin lock protecting the shared area has an IRQL equal to the DIRQL at which the device interrupts. While the critical-section routine holds the spin lock and accesses the shared area at DIRQL, the ISR cannot be run in a uniprocessor machine because the device interrupt is masked off, as mentioned in Always Preemptible and Always Interruptible.And in a symmetric multiprocessor machine, the ISR still cannot acquire the spin lock protecting the shared data while the critical-section routine holds the spin lock and accesses the shared data at DIRQL