DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
SVR5

SLEEP_LOCK(D3)


SLEEP_LOCK -- acquire a sleep lock

Synopsis

   #include <sys/ksynch.h>
   #include <sys/ddi.h>
   

void SLEEP_LOCK(sleep_t *lockp, int priority);

Description

SLEEP_LOCK acquires the sleep lock specified by lockp. If the lock is not immediately available, the caller is put to sleep (the caller's execution is suspended and other processes may be scheduled) until the lock becomes available to the caller, at which point the caller wakes up and returns with the lock held.

The caller will not be interrupted by signals while sleeping inside SLEEP_LOCK.

Arguments


lockp
Pointer to the sleep lock to be acquired.

priority
A hint to the scheduling policy as to the relative priority the caller wishes to be assigned while running in the kernel after waking up.

Return values

None

Usage

priority argument

Valid values for priority are:

pridisk
Priority appropriate for disk driver.

prinet
Priority appropriate for network driver.

pritty
Priority appropriate for terminal driver.

pritape
Priority appropriate for tape driver.

prihi
High priority.

primed
Medium priority.

prilo
Low priority.

Drivers may use these values to request a priority appropriate to a given type of device or to request a priority that is high, medium or low relative to other activities within the kernel.

It is also permissible to specify positive or negative offsets from the values defined above. Positive offsets result in more favorable priority. The maximum allowable offset in all cases is 3 (for example, pridisk+3 and pridisk-3 are valid values but pridisk+4 and pridisk-4 are not valid). Offsets can be useful in defining the relative importance of different locks or resources that may be held by a given driver. In general, a higher relative priority should be used when the caller is attempting to acquire a highly contended lock or resource, or when the caller is already holding one or more locks or kernel resources upon entry to SLEEP_LOCK.

The exact semantic of the priority argument is specific to the scheduling class of the caller, and some scheduling classes may choose to ignore the argument for the purposes of assigning a scheduling priority.

Context and synchronization

User or blockable context.

Sleep locks are not recursive. A call to SLEEP_LOCK attempting to acquire a lock that is currently held by the calling context will result in deadlock.

Hardware applicability

All

Version applicability

ddi: 5, 5mp, 6, 6mp, 7, 7mp, 7.1, 7.1mp, 8, 8mp

References

SLEEP_ALLOC(D3), SLEEP_DEALLOC(D3), SLEEP_LOCK_SIG(D3), SLEEP_LOCKAVAIL(D3), SLEEP_LOCKOWNED(D3), SLEEP_TRYLOCK(D3), SLEEP_UNLOCK(D3)

``Sleep locks'' in HDK Technical Reference


19 June 2005
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005