Locking Strategies

Any MP system needs a mechanism for protecting global data structures while allowing multiple processors to execute code concurrently in the system. HP-UX provides for this concurrency through the locking strategies of spinlocks and semaphores.

Locks provide mutual exclusion in critical sections. Data structures manipulated in these sections are protected by these locks, to prevent errors from occurring if multiple threads of control operate on the data at the same time.
A lock permits only one thread of control at a time to operate on critical data.




	NOTE: Every shared kernel data structure is protected by either a spinlock or a semaphore.

Spinlocks implement a "busy wait condition" for a resource. If a processor attempts to obtain a spinlock being held by another processor, it will wait until the lock is released.
Spinlocks can be acquired on an interrupt stack. A deadlock can arise, however, if a processor takes an interrupt while holding a spinlock and the interrupt code tries to acquire the same spinlock. To prevent this from occurring, HP-UX requires the spl level to be raised whenever a spinlock is acquired. When the spinlock is released, the prior spl level is reverted to. Once a spinlock is acquired, the spl level should not be lowered within the spinlocked critical section.
Spinlocks are used to synchronize access to data between multiple processors, and as such, have little value in a uniprocessor system. Within the kernel the MP_SPINLOCK() macro checks the uniprocessor flag and returns if not an MP system.
Kernel semaphores control access through blocking strategies. With blocking semaphores, a processor attempting to acquire a semaphore already held by another processor will put its current thread to sleep and context switch to another task.
Semaphores are used to provide mutual exclusion or to synchronize access between multiple processes or threads, regardless of how many processors there are.




	NOTE: Kernel semaphores differ from IPC SystemV semaphores.

In an MP system the decision to use spinlocks or blocking semaphores comes down to a performance issue based on the expected time to busy wait versus the overhead of a process context switch. Additionally, if the lock must be taken while on the Interrrupt Control Stack(ICS), then the process cannot block and must use spinlock. Spinlocks require less overhead than semaphore operations.

Attributes of Spinlocks and Semaphores

The set of data structures protected by a single semaphore or spinlock is defined as a "protection class."




	NOTE: Every shared kernel data structure is a member of one protection class.

Semaphores have "priority" and "order."

In this context, priority refers to the scheduling priority to which a process or thread of control is promoted while possessing the semaphore.
Order refers to a sequential (numeric) arrangement used in detecting and resolving deadlocks.

Alpha semaphores (discussed shortly) have an associated lock order (sa_order) to prevent a deadlock situation, which can happen if threads on two processors are performing similar operations. The semaphore with the lowest lock order is always locked first. This guarantees that multiple semaphores are locked in the same order by all threads, thus reducing the opportunity for deadlock.

The kernel has assertions to enforce this lock ordering in a debug kernel. Definitions and values of protection class, priority, and order are maintained in the semglobal.h header file.

Locking Strategies

Technical documentation

» Table of Contents

Attributes of Spinlocks and Semaphores