SCO OpenServer


ilockb, iunlockb -- lock and unlock critical code section and disable interrupts directly


   #include <sys/ci/cilock.h>

int ilockb(lock_xxtab) struct lockb *lock_xxtab;

void iunlockb(lock_xxtab, oldspl) struct lockb *lock_xxtab; int oldspl;


ilockb designates that a critical code section be accessible only by a single processor for a short period of time. ilockb( ) is a faster version of the lockb(D3oddi) routine. ilockb is used in conjunction with a call to iunlockb.

iunlockb unlocks the critical code section, restoring multiprocessor access, by releasing a lock previously acquired with ilockb. The spl value is restored to oldspl. If the value of oldspl is set to -1, then iunlockb does not restore the spl value; the driver must restore the spl value after the call to iunlockb completes. The address of lock_xxtab must be the same address used in the ilockb call. In addition, the order in which these two routines are called is critical. iunlockb cannot be called before ilockb, iunlockb cannot unlock code using an address other than that used by ilockb, and the order in which locks are acquired must be followed precisely in reverse order when unlocking.


Address of a lockb(D4oddi) structure.

spl level, returned by ilockb, to be restored by iunlockb.

Return values

ilockb( ) returns the previous spl value. iunlockb( ) does not return a value.


ilockb( ) is faster than lockb( ) because it disables interrupts by clearing the interrupt enable flag (IF bit) of the processor rather than by programming the external interrupt controller.

ilockb( ) cannot be used if the critical region protected can do a context switch, for example by sleeping. If you have any doubt, use lockb( ) instead.

ilockb can cause the operating system to panic in two different ways. The first way is if one thread holds a lock too long while another thread is trying to acquire it; the panic occurs after one million attempts to acquire the lock. The second way occurs if all available locks have been acquired and there are no more available.

In addition, ilockb leaves all interrupts blocked upon return. If the critical code section takes longer than a clock tick to execute, the system clock is retarded.

iunlockb can panic the operating system if iunlockb is not releasing the most recently acquired lock (acquired by a previous call to ilockb), or if the process calling iunlockb does not own the argument lock as a result of a previous call to ilockb.

See also lockb(D3oddi) and clockb(D3oddi) for descriptions of ordinary locking and conditional locking.


Context and synchronization

Non-blockable, interrupt, user, or blockable context.

Hardware applicability


Version applicability

oddi: 2mp, 3, 3mp, 4, 4mp, 5, 5mp, 6, 6mp

SVR5 DDI compatibility

DDI does not support these locking functions, but provides a different (and richer) set of locking primitives; see ``Spin locks (DDI)'' in HDK Technical Reference.


clockb(D3oddi), lockb(D3oddi), spl(D3oddi)

``Critical code section'' in HDK Technical Reference
``Spin locks (ODDI)'' in HDK Technical Reference

19 June 2005
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 5 HDK - June 2005