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
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005