SMPV211 - Understanding Spinlocks

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

OS/2 for SMP V2.11 Reference
Notices Overview of OS/2 for SMP Version 2.11 Platform Specific Drivers (PSDs) Understanding Spinlocks Device Drivers In OS/2 for SMP V2.11 Application Considerations Avoiding Device Driver Deadlocks New Device Helper (DevHlp) Routines New Kernel Debugger Commands The Single Processor Utility Program OS/2 for SMP V2.11 Tools Appendix A Glossary

OS/2 for SMP V2.11 provides synchronization and serialization using spinlocks. A spinlock is simply a section of code that executes in a tight loop waiting for a variable to be cleared.

Spinlocks

The defined mechanism for protection of critical resources in OS/2 MP is a spinlock. A spinlock is a serialization mechanism that is used to restrict access to a critical resource to the owner of the spinlock. Spinlocks are implemented in the LockManager, which is part of the kernel, and are manipulated by using the new MPHelper services. The act of acquiring a spinlock can be thought of as locking the spinlock.

The reason spinlocks are used for critical resource protection instead of disabling interrupts, is disabling interrupts no longer works in an MP environment. CLI and STI will only work on the processor on which the instruction is executing. It will not prevent another processor from executing task time or interrupt code from the same device driver. Even though the kernel is non-preemptive, another processor can enter the kernel, and hence a device driver at any time. That means that CLI will not provide the same protection as on a single processor system. CLI/STI must be avoided.

MP aware device drivers will use spinlocks to protect critical resources. A spinlock must be allocated for each critical resource. Spinlock allocation should be done during initialization. When access to the resource is required, the device driver will try to lock the spinlock for the resource. If the spinlock is already locked then the processor will "spin" waiting for the lock to become available. Once the spinlock is acquired (locked) the device driver has exclusive access to the critical resource. The spinlock should remain locked for a VERY short time. When done with the resource the spinlock is released (unlocked).

Because spinlocks are for VERY SHORT durations, interrupts must be disabled while a spinlock is locked. If interrupts were enabled the path of execution could be expanded indefinitely by interrupt handlers. To enforce this rule, the LockManager will save the state of the interrupt flag and disable interrupts when a spinlock is locked. When the spinlock is unlocked, the LockManager will restore the interrupt flag to his original state. This allows device drivers to be unaware of the interrupt flag state while locking and unlocking spinlocks. The device driver, however, must not enable interrupts while owning a spinlock. If interrupts were enabled there are two possible effects. First is the uncontrolled expansion of the time a spinlock is owned. Second is the possibility of deadlock.

A spinlock is defined such that an attempt to acquire a spinlock which is currently owned by another processor, makes you spin (i.e. a tight loop of code which waits for the spinlock to be released). Spinlocks should be used sparingly, and should only be owned for very short periods of time, as spinning prevents the processor from doing any additional work. Spinlocks have different properties depending on whether it is a kernel or device driver spinlock. Spinlocks have been used because it is more expensive to reschedule a thread that is trying to acquire a spinlock than it would be waiting for the lock to clear.

Properties of Spinlocks

It is important to note the differences in the various types of spinlocks. Properties of kernel spinlocks:

• can have nested ownership.
• can use a level to enforce a lock hierarchy.
• can not be owned while outside of the kernel.
• can only be owned for very short periods of time.
• can not block while owning a spinlock.

Properties of device driver spinlocks:

• can't have nested ownership.
• can't use a level to enforce a lock hierarchy.
• can be held outside of the kernel.
• can only be owned for very short periods of time.

There is a different type of spinlock which is exported to subsystems. These locks are used to provide an efficient MP safe CLI/STI substitute for protecting data structures that are shared between task-time and interrupt-time code.

Properties of subsystem spinlocks:

• can't have nested ownership.
• can't use a level to enforce a lock hierarchy.
• can be held outside of the kernel.
• can only be used for very short periods of time.
• each processor can hold only one subsystem spinlock at a time.

A suspend lock, is defined such that an attempt to acquire a suspend lock which is currently owned by another processor places the current thread into a blocked state, and causes a reschedule. The thread's which are blocked on suspend locks will awaken when the lock is released. Suspend locks are only used inside the kernel.

Properties of a kernel suspend lock:

• can have nested ownership.
• can use a level to enforce a lock hierarchy.
• can not be owned while outside of the kernel.
• can be owned for long periods of time.
• can not block while owning a suspend lock.

When a spinlock is acquired, the lock manager automatically saves the state of the interrupt flag, then disables interrupts before returning to the caller. It restores the state of the interrupt flag when the lock is released. The kernel will panic if an interrupt is taken while owning a spinlock.

Spinlock Use Guidelines

Here are some guidelines on using spinlocks to protect critical resources.

• Define spinlocks only for critical resources. A read only I/O port is not a critical resource. A set of read only I/O ports that must all be read before a decision is made IS a critical resource.
• Do not define too many spinlocks.
• Use spinlocks for VERY SHORT durations only. As a general rule, calls should be avoided while owning a spinlock.
• Leave interrupts disabled after locking a spinlock. This prevents interrupts on the same processor and possible deadlock.
• Be careful to not make any calls that may try to lock a spinlock that is already locked. ADDs, when making asynchronous callbacks, can be reentered at their IORB entry point.
• Be aware that DevHelp_Block called with spinlocks locked will unlock them. When the block wakes up spinlocks must be reacquired.
• Never make a call that could block while owning a spinlock. For example, some DevHelp calls can block.