Specifications

D
evice Driver Programming
17-20
exclusion mechanisms, and coordinating client-server interaction among processes.
Descriptions of the tools that are pertinent to development of a user-level device driver are
provided in the sections that follow.
Busy-Wait Mutual Exclusion Tools 17
PowerUX busy-wait mutual exclusion tools include a low-overhead busy-wait mutual
exclusion variable and a corresponding set of macros. The busy-wait mutual exclusion
variable is a data structure known as a spin lock. This variable is defined in the file
<sys/lwp_synch.h>. The spin lock has two states: locked and unlocked. When initial-
ized, the spin lock is in the unlocked state. If you want to use spin locks to coordinate
access to shared resources, you must allocate them in your application program and locate
them in a shared memory region.
The busy-wait mutual exclusion macros allow you to initialize, lock, and unlock spin
locks and determine whether or not a particular spin lock is locked. These macros are
briefly described as follows:
spin_init initialize a spin lock to the unlocked state
spin_trylock attempt to lock a specified spin lock
spin_unlock unlock a specified spin lock
spin_islock determine whether or not a specified spin lock is locked
You can use spin locks to synchronize processes’ access to the device register region and
the driver status region and to synchronize processes’ access to shared data that can be
modified at program and interrupt level.
Procedures for using the busy-wait mutual exclusion variable and the macros are fully
explained in the PowerUX Real-Time Guide. An example program that illustrates their use
is provided. Reference information on the macros is provided in the
spin_trylock(2) system manual page.
Rescheduling Control Tools 17
To use busy-wait mutual exclusion effectively, lock hold times must be small and
predictable. Rescheduling and signal handling are major sources of unpredictability. If a
context switch occurs or a signal is received while a process is running with a spin lock
held, the hold time on the spin lock increases dramatically. To provide you with the means
to control rescheduling and signal handling, a rescheduling variable has been developed.
A rescheduling variable is a data structure that controls a single thread’s vulnerability to
rescheduling. This variable is defined in the file <sys/lwp_synch.h>. You allocate the
variable in your application, notify the kernel of its location, and manipulate it directly
from your application to disable and re-enable rescheduling. While rescheduling is
disabled, quantum expirations, preemptions, and certain types of signals are held.
The resched_cntl(2) system call enables you to perform a variety of operations
specific to the rescheduling variable. These include initializing a rescheduling variable,
informing the kernel of its location, obtaining its location, and setting a limit on the length
of time that rescheduling can be deferred. A set of rescheduling macros enables you to dis-