NdisAllocateSpinLock function (ndis.h)
The NdisAllocateSpinLock function initializes a variable of type NDIS_SPIN_LOCK, used to synchronize access to resources shared among non-ISR driver functions.
void NdisAllocateSpinLock( [out] PNDIS_SPIN_LOCK SpinLock );
Pointer to an opaque variable that represents a spin lock.
Before a driver calls NdisAcquireSpinLock, NdisDprAcquireSpinLock, or any of the NdisInterlockedXxx functions, it must call NdisAllocateSpinLock to initialize the spin lock passed as a required parameter to these NdisXxx functions. The caller must provide nonpaged storage for the variable at SpinLock .
After calling NdisAllocateSpinLock, the driver can call NdisAcquireSpinLock to obtain exclusive use of the resource(s) the spin lock protects. When resource access is complete, the driver calls NdisReleaseSpinLock so that other driver functions can access the resource(s) protected by that spin lock.
As a general rule, to improve performance a driver should use different locks to protect different critical sections. Thus, a driver might initialize more than one spin lock with NdisAllocateSpinLock.
Each spin lock that a driver allocates protects a discrete set of shared resources from simultanous access by driver functions that run at IRQL <= DISPATCH_LEVEL. For example, a driver that maintains an internal queue of packets might initialize one spin lock to protect its queue and another to protect a set of state variables that several driver functions, not including the MiniportInterrupt or MiniportDisableInterruptEx function, access while the driver is processing packets.
NdisAcquireSpinLock raises the IRQL to DISPATCH_LEVEL and stores the old IRQL in the spin lock. Releasing the spin lock sets the IRQL to the value stored in the spin lock. Because NDIS sometimes enters drivers at PASSIVE_LEVEL, problems can arise with the following code:
NdisAcquireSpinLock(A); NdisAcquireSpinLock(B); NdisReleaseSpinLock(A); NdisReleaseSpinLock(B);
A driver should not access spin locks in this sequence for the following reasons:
- Between NdisReleaseSpinLock(A) and NdisReleaseSpinLock(B) the code is running at PASSIVE_LEVEL instead of DISPATCH_LEVEL and is subject to inappropriate interruption.
- After NdisReleaseSpinLock(B) the code is running at DISPATCH_LEVEL which could cause the caller to fault at much later time with an IRQL_NOT_LESS_OR_EQUAL stop error.
A miniport driver cannot use a spin lock to protect resources that its non-ISR functions share with its MiniportInterrupt or MiniportDisableInterruptEx function. To access resources shared with a MiniportInterrupt or MiniportDisableInterruptEx function, a miniport driver must call NdisMSynchronizeWithInterruptEx to have its MiniportSynchronizeInterrupt function access those resources at DIRQL.
When a driver no longer requires resource protection, for example, when a NIC is being removed and the driver is releasing the resources it allocated for that NIC, the driver calls NdisFreeSpinLock.
Freeing a spin lock and releasing a spin lock are potentially confusing. NdisFreeSpinLock clears the memory at SpinLock so it no longer represents a spin lock. Releasing an acquired spin lock with NdisReleaseSpinLock simply allows another thread of execution to acquire that spin lock.
For more information about acquiring and releasing NDIS spin locks, see Synchronization and Notification in Network Drivers.
Callers of NdisAllocateSpinLock can run at any IRQL. Usually a caller is running at IRQL = PASSIVE_LEVEL during initialization.
|Minimum supported client||Supported for NDIS 6.0 and NDIS 5.1 drivers (see NdisAllocateSpinLock (NDIS 5.1)) in Windows Vista. Supported for NDIS 5.1 drivers (see NdisAllocateSpinLock (NDIS 5.1)) in Windows XP.|
|Header||ndis.h (include Ndis.h)|
|IRQL||Any level (see Remarks section)|
|DDI compliance rules||SpinLockDpr(ndis), SpinLockDprRelease(ndis), SpinlockRelease(ndis)|
See alsoNdisInterlockedInsertHeadList NdisInterlockedInsertTailList NdisInterlockedRemoveHeadList NdisMSynchronizeWithInterruptEx
Submit and view feedback for