Protecting critical code

Critical code is a section of code that must be executed atomically; see ``Critical code section''. On uniprocessing configurations, only an interrupt generated by the hardware can interfere with the atomic execution, so issuing the spl(D3oddi) functions to prevent interrupts while the code is executing is adequate to protect the critical code.

On multiprocessing systems, interrupts can come from any processor, or two task-level processes executing on different processors could access the same resource. Consequently, the locking functions listed in ``Mutual exclusion locking functions'' must be used to provide mutual exclusion access to critical code.

Mutual exclusion locking functions

Function	Description
atomic(D3oddi) family	quick locks for basic arithmetic and bit operations
clockb(D3oddi), cunlockb(D3oddi)	conditionally lock critical code sections
lockb(D3oddi), lockb5(D3oddi), unlockb(D3oddi)	general locking functions
ilockb(D3oddi), iunlockb(D3oddi)	block interrupts for short critical code sections
mdi_trylock(D3mdi), mdi_tryunlock(D3mdi), mdi_tryunlock_init(D3mdi)	MDI trylock functions
MPSTR_QLOCK(D3str), MPSTR_QRELE(D3str)	lock STREAMS queue
MPSTR_STPLOCK(D3str), MPSTR_STPRELE(D3str)	lock Stream head
tc_tlock(D3oddi), tc_tunlock(D3oddi), tc_ctlock(D3oddi), tc_ctunlock(D3oddi)	mutual exclusion to a tty structure

Note the following about using the locking functions:

• Any driver data that might be modified by more than one CPU must be locked for access by one processor at a time.

• Any lock that is held when sleep(D3oddi) is called is released by the kernel at that time. When a process resumes as a result of a wakeup(D3oddi) call, the lock is then reacquired by the kernel in the same order as it was originally acquired.

• A lock should be held for as short a time as possible to avoid degrading system performance. When a lock is acquired, all interrupts (including clock interrupts) to that CPU are disabled, and a process on another CPU might be blocked waiting for that lock.

• For simple arithmetic and bit manipulation operations that must be executed atomically, use the quick locks documented on the atomic(D3oddi) manual page.

• No spl(D3oddi) calls should be issued beteween a locking function and its corresonding unlock function.

• Code that uses the locking functions will run on a uniprocessor configuration without modification.