int ilockb(lock_xxtab) struct lockb *lock_xxtab;
void iunlockb(lock_xxtab, oldspl) struct lockb *lock_xxtab; int oldspl;
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.
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.
``Critical code section'' in HDK Technical Reference
``Spin locks (ODDI)'' in HDK Technical Reference