In addition to protecting shared data, drivers often need to synchronize execution among multiple threads.
Condition variables are a standard form of thread synchronization. They are designed to be used with mutexes. The associated mutex is used to ensure that a condition can be checked atomically, and that the thread can block on the associated condition variable without missing either a change to the condition or a signal that the condition has changed.
The condvar(9F) functions are:
Signals all threads waiting on the condition variable.
Destroys a condition variable.
Initializes a condition variable.
Signals one thread waiting on the condition variable.
Waits for condition, time-out, or signal. See Threads Unable to Receive Signals.
Waits for condition or time-out.
Waits for condition.
Waits for condition or return zero on receipt of a signal. See Threads Unable to Receive Signals.
Declare a condition variable of type kcondvar_t for each condition. Usually, the condition variables are declared in the driver's soft-state structure. Use cv_init(9F) to initialize each condition variable. Similar to mutexes, condition variables are usually initialized at attach(9E) time. A typical example of initializing a condition variable is:cv_init(&xsp->cv, NULL, CV_DRIVER, NULL);.
For a more complete example of condition variable initialization, see Driver Autoconfiguration.
To use condition variables, follow these steps in the code path waiting for the condition:
Acquire the mutex guarding the condition.
Test the condition.
If the test results do not allow the thread to continue, use cv_wait(9F) to block the current thread on the condition. The cv_wait(9F) function releases the mutex before blocking the thread and reacquires the mutex before returning. On return from cv_wait(9F), repeat the test.
After the test allows the thread to continue, set the condition to its new value. For example, set a device flag to busy.
Release the mutex.
Follow these steps in the code path to signal the condition:
Acquire the mutex guarding the condition.
Set the condition.
Signal the blocked thread with cv_broadcast(9F).
Release the mutex.
The following example uses a busy flag along with mutex and condition variables to force the read(9E) routine to wait until the device is no longer busy before starting a transfer.
Example 1 Using Mutexes and Condition Variablesstatic int
xxread(dev_t dev, struct uio *uiop, cred_t *credp)
{
struct xxstate *xsp;
/* ... */
mutex_enter(&xsp->mu);
while (xsp->busy)
cv_wait(&xsp->cv, &xsp->mu);
xsp->busy = 1;
mutex_exit(&xsp->mu);
/* perform the data access */
}
static uint_t
xxintr(caddr_t arg)
{
struct xxstate *xsp = (struct xxstate *)arg;
mutex_enter(&xsp->mu);
xsp->busy = 0;
cv_broadcast(&xsp->cv);
mutex_exit(&xsp->mu);
}
If a thread is blocked on a condition with cv_wait(9F) and that condition does not occur, the thread would wait forever. To avoid that situation, use cv_timedwait(9F), which depends upon another thread to perform a wakeup. cv_timedwait() takes an absolute wait time as an argument. cv_timedwait() returns -1 if the time is reached and the event has not occurred. cv_timedwait() returns a positive value if the condition is met.
cv_timedwait(9F) requires an absolute wait time expressed in clock ticks since the system was last rebooted. The wait time can be determined by retrieving the current value with ddi_get_lbolt(9F). The driver usually has a maximum number of seconds or microseconds to wait, so this value is converted to clock ticks with drv_usectohz(9F) and added to the value from ddi_get_lbolt(9F).
The following example shows how to use cv_timedwait(9F) to wait up to five seconds to access the device before returning EIO to the caller.
Example 2 Using cv_timedwait()clock_t cur_ticks, to;
mutex_enter(&xsp->mu);
while (xsp->busy) {
cur_ticks = ddi_get_lbolt();
to = cur_ticks + drv_usectohz(5000000); /* 5 seconds from now */
if (cv_timedwait(&xsp->cv, &xsp->mu, to) == -1) {
/*
* The timeout time 'to' was reached without the
* condition being signaled.
*/
/* tidy up and exit */
mutex_exit(&xsp->mu);
return (EIO);
}
}
xsp->busy = 1;
mutex_exit(&xsp->mu);
Although device driver writers generally prefer to use cv_timedwait(9F) over cv_wait(9F), sometimes cv_wait(9F) is a better choice. For example, cv_wait(9F) is better if a driver is waiting on the following conditions:
Internal driver state changes, where such a state change might require some command to be executed, or a set amount of time to pass
Something the driver needs to single-thread
Some situation that is already managing a possible timeout, as when "A" depends on "B," and "B" is using cv_timedwait(9F)
A driver might be waiting for a condition that cannot occur or will not happen for a long time. In such cases, the user can send a signal to abort the thread. Depending on the driver design, the signal might not cause the driver to wake up.
cv_wait_sig(9F) allows a signal to unblock the thread. This capability enables the user to break out of potentially long waits by sending a signal to the thread with kill(1) or by typing the interrupt character. cv_wait_sig(9F) returns zero if it is returning because of a signal, or nonzero if the condition occurred. However, see Threads Unable to Receive Signals for cases in which signals might not be received.
The following example shows how to use cv_wait_sig(9F) to allow a signal to unblock the thread.
Example 3 Using cv_wait_sig()mutex_enter(&xsp->mu);
while (xsp->busy) {
if (cv_wait_sig(&xsp->cv, &xsp->mu) == 0) {
/* Signaled while waiting for the condition */
/* tidy up and exit */
mutex_exit(&xsp->mu);
return (EINTR);
}
}
xsp->busy = 1;
mutex_exit(&xsp->mu);
cv_timedwait_sig(9F) is similar to cv_timedwait(9F) and cv_wait_sig(9F), except that cv_timedwait_sig() returns -1 without the condition being signaled after a timeout has been reached, or 0 if a signal (for example, kill(2)) is sent to the thread.
For both cv_timedwait(9F) and cv_timedwait_sig(9F), time is measured in absolute clock ticks since the last system reboot.