Using Spin Locks

  在网上看了很多贴都没有搞清楚！最后还是在书上看到了。。转给需要的看看！应该说的够清楚的了

Using Spin Locks
There are two major kinds of spin locks provided by the kernel. They are distinguished by the IRQL level at which they are used.

－Interrupt spin locks.?/b>

   These synchronize and provide access to driver data structures shared by      multiple-driver routines. Interrupt spin locks are acquired at the DIRQL associated with the device.


－Executive spin locks.?/b>

   These guard various operating system data structures, and their associated IRQL is DISPATCH_LEVEL.


When a driver uses Interrupt spin locks, operation is straightforward. The function KeSynchronizeExecution is described in chapter 8.

Executive spin locks are more complicated to work with. The following steps must be followed when using Executive spin locks:

－Decide what data items must be guarded and how many spin locks should be used. Additional spin locks allow finer granularity of access to the data. However, the possibility of deadlock is present whenever acquisition of more than one spin lock at a time is required.

－Reserve space for a data structure of type KSPIN_LOCK for each lock. Storage for the spin lock must be in nonpaged pool. Usually, the spin lock is declared in the device or controller extension.

－Initialize the spin lock once by calling KeInitializeSpinLock. This function can be called from any IRQL level, though it is most commonly used from the DriverEntry routine.

－Call KeAcquireSpinLock before touching any resource guarded by a spin lock. This function raises IRQL to DISPATCH_LEVEL, acquires the spin lock, and returns the previous IRQL value. This function must be called at or below DISPATCH_LEVEL IRQL. If the code is already at DISPATCH_LEVEL, a more efficient call is KeAcquireSpinLockFromDpcLevel.

－When access to the resource is complete, use the KeReleaseSpinLock function to free the lock. This function is called from DISPATCH_LEVEL IRQL and it restores IRQL to its original value. If the original level was known to be DISPATCH_LEVEL, a more efficient call would be KeReleaseSpinLockFromDpcLevel, which releases the lock without changing IRQL.

Some driver support routines (like the interlock lists and queues described in the next section) use Executive spin locks for protection. In these cases, the only requirement is that the spin lock object be initialized. The driver support routines that manage the interlocked object will acquire and release the spin lock on the driver's behalf.

Rules for Using Spin Locks
Spin locks aren't terribly difficult to use, but there are a few rules that should be followed.

－Be sure to release a spin lock as soon as possible because while holding it, other CPU activity may be blocked. The official DDK recommendation is not to hold a spin lock for more than about 25 microseconds.

－Don't cause any hardware or software exceptions while holding the spin lock. This is a guaranteed system crash.

D－on't access any page code or data while holding the spin lock. This may result in a page fault exception.

－Don't try to acquire a spin lock the CPU already owns. This leads to a deadlock situation since the CPU freezes up, waiting for itself to release the spin lock.

－Avoid driver designs that depend on holding multiple spin locks simultaneously. Without careful design, this can lead to a deadly embrace condition. If multiple spin locks must be used, ensure that all code paths agree to acquire them in a fixed order and release them in the exact reverse order.