SEMAPHORE(9F) | Kernel Functions for Drivers | SEMAPHORE(9F) |
semaphore
, sema_init
,
sema_destroy
, sema_p
,
sema_p_sig
, sema_v
,
sema_tryp
—
#include <sys/ksynch.h>
void
sema_init
(ksema_t *sp,
uint_t val, char *name,
ksema_type_t type, void
*arg);
void
sema_destroy
(ksema_t *sp);
void
sema_p
(ksema_t *sp);
void
sema_v
(ksema_t *sp);
int
sema_p_sig
(ksema_t *sp);
int
sema_tryp
(ksema_t *sp);
NULL
. (Non-NULL
strings
are legal, but they are a waste of kernel memory.)SEMA_DRIVER
is supported.NULL
.sema_p
() and atomically incremented by
sema_v
(). The value must always be greater than or
equal to zero. If sema_p
() is called and the value is
zero, the calling thread is blocked until another thread performs a
sema_v
() operation on the semaphore.
Semaphores are initialized by calling
sema_init
(). The argument,
val, gives the initial value for the semaphore. The
semaphore storage is provided by the caller but more may be dynamically
allocated, if necessary, by sema_init
(). For this
reason, sema_destroy
() should be called before
deallocating the storage containing the semaphore.
The sema_p_sig
() function decrements the
semaphore, as does sema_p
(). However, if the
semaphore value is zero, sema_p_sig
() will return
without decrementing the value if a signal (that is, from
kill(2)) is pending for the thread.
The sema_tryp
() function will decrement
the semaphore value only if it is greater than zero, and will not block.
sema_init
() and
sema_destroy
(), which can be called from user or
kernel context only. None of these functions can be called from a high-level
interrupt context. In most cases, sema_v
() and
sema_p
() should not be called from any interrupt
context.
If sema_p
() is used from interrupt
context, lower-priority interrupts will not be serviced during the wait.
This means that if the thread that will eventually perform the
sema_v
() becomes blocked on anything that requires
the lower-priority interrupt, the system will hang.
For example, the thread that will perform the
sema_v
() may need to first allocate memory. This
memory allocation may require waiting for paging I/O to complete, which may
require a lower-priority disk or network interrupt to be serviced. In
general, situations like this are hard to predict, so it is advisable to
avoid waiting on semaphores or condition variables in an interrupt
context.
Similar to many other synchronization mechanisms, semaphores should not be used in any code path that requires synchronization while handling system panic, at which time many of the semaphore operations become no-ops.
Writing Device Drivers
July 30, 2018 | OmniOS |