Sleep locks

Sleep locks are DDI synchronization primitives that are used for serializing access to a shared resource or critical code region when spin locks are inappropriate.

Note the following semantics when using the sleep locks:

• Sleep locks are not recursive in nature. If a context attempts to lock a sleep lock that it already has acquired, deadlock will occur. This condition is checked if _LOCKTEST is defined in a DEBUG version of the driver.

• Sleep locks cannot be acquired when the caller has no process context.

• Sleep locks normally block the calling process if the lock is not available in the requested mode. A function is provided to do a trylock on a sleep lock in contexts where the driver may not block.

• Do not lock a sleep lock at a signalable priority when it is nested inside another sleep lock. You should use sleep locks at signalable priority sparingly as this can lead to the following problem: Consider the case where a context blocks attempting to sleep lock (signalable) a resource when it already has another resource sleep locked. If the context receives a STOP signal, it will STOP holding a resource that is locked for a potentially long time and possibly forever.

Sleep locks are supported for all DDI versions beginning with version 5 and 5mp.

SLEEP_ALLOC(D3)

allocate and initialize a sleep lock

SLEEP_LOCK(D3)

acquire a sleep lock

SLEEP_LOCK_SIG(D3)

acquire a sleep lock

SLEEP_TRYLOCK(D3)

try to allocate a sleep lock

SLEEP_LOCKAVAIL(D3)

query whether a sleep lock is available

SLEEP_LOCKOWNED(D3)

query whether a sleep lock is held by the caller

SLEEP_DEALLOC(D3)

deallocate an instance of a sleep lock

pri(D5)

priorities for sleep locks