HDK Technical Reference

Critical code section

A critical code section is a piece of software that must be executed atomically to preserve data integrity, hardware integrity, and access serialization.

The ability of code to work properly when two or more threads that use a certain resource are executing at the same time is referred to as concurrency; see ``Concurrency''.

Critical code sections include all of the following:

On uniprocessor systems, kernel context preemption points are standardized and well-defined; calling spl(D3) or spl(D3oddi) to prevent interrupts from being serviced while a critical region executes is adequate. Multiprocessor systems require more sophisticated mechanisms to protect critical code than uniprocessing systems.

On a multiprocessor system, multiple requestor-level or process-level contexts may be executing on different processors at any given time, and the kernel is completely preemptable so executing driver code can be preempted under most circumstances, unless it is holding a lock. spl( ) only prevents interrupts from being serviced on the processor where the code is executed; the interrupt may be serviced (handler executed) on another processor.

Timeout routines are also inadequate for protecting critical code on multiprocessors because the actual execution of all callback routines is not only asynchronous but also could be executed on any processor. The only way to protect any driver code is to use locks to fulfill this need; see ``Synchronization primitives''. Acquiring locks guarantees serialized access to critical regions of code and protects the calling contexts from being preempted in favor of another context, until the lock is dropped.

To be precise, locks do not protect critical regions of code, but rather protect critical data structures during simultaneous access by multiple contexts executing the same code at the same time. Not all data structures are critical, and multiple reads of an otherwise critical data structure would not require protection, but simultaneous reads and writes would. Furthermore, critical data structures are not critical under all circumstances. For example, access to data structures in the initialization context does not need to be protected because only one context can access the data structure at that time.

Locks are used in a number of situations to protect critical data structures. Some common situations for which locks are appropriate are:

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