1 SEMAPHORE(9F) Kernel Functions for Drivers SEMAPHORE(9F) 2 3 NAME 4 semaphore, sema_init, sema_destroy, sema_p, sema_p_sig, sema_v, sema_tryp 5 - semaphore functions 6 7 SYNOPSIS 8 #include <sys/ksynch.h> 9 10 void 11 sema_init(ksema_t *sp, uint_t val, char *name, ksema_type_t type, 12 void *arg); 13 14 void 15 sema_destroy(ksema_t *sp); 16 17 void 18 sema_p(ksema_t *sp); 19 20 void 21 sema_v(ksema_t *sp); 22 23 int 24 sema_p_sig(ksema_t *sp); 25 26 int 27 sema_tryp(ksema_t *sp); 28 29 INTERFACE LEVEL 30 illumos DDI specific (illumos DDI). 31 32 PARAMETERS 33 sp A pointer to a semaphore, type ksema_t. 34 35 val Initial value for semaphore. 36 37 name Descriptive string. This is obsolete and should be NULL. 38 (Non-NULL strings are legal, but they are a waste of kernel 39 memory.) 40 41 type Variant type of the semaphore. Currently, only SEMA_DRIVER is 42 supported. 43 44 arg Type-specific argument; should be NULL. 45 46 DESCRIPTION 47 These functions implement counting semaphores as described by Dijkstra. 48 A semaphore has a value which is atomically decremented by sema_p() and 49 atomically incremented by sema_v(). The value must always be greater 50 than or equal to zero. If sema_p() is called and the value is zero, the 51 calling thread is blocked until another thread performs a sema_v() 52 operation on the semaphore. 53 54 Semaphores are initialized by calling sema_init(). The argument, val, 55 gives the initial value for the semaphore. The semaphore storage is 56 provided by the caller but more may be dynamically allocated, if 57 necessary, by sema_init(). For this reason, sema_destroy() should be 58 called before deallocating the storage containing the semaphore. 59 60 The sema_p_sig() function decrements the semaphore, as does sema_p(). 61 However, if the semaphore value is zero, sema_p_sig() will return without 62 decrementing the value if a signal (that is, from kill(2)) is pending for 63 the thread. 64 65 The sema_tryp() function will decrement the semaphore value only if it is 66 greater than zero, and will not block. 67 68 CONTEXT 69 These functions can be called from user, interrupt, or kernel context, 70 except for sema_init() and sema_destroy(), which can be called from user 71 or kernel context only. None of these functions can be called from a 72 high-level interrupt context. In most cases, sema_v() and sema_p() 73 should not be called from any interrupt context. 74 75 If sema_p() is used from interrupt context, lower-priority interrupts 76 will not be serviced during the wait. This means that if the thread that 77 will eventually perform the sema_v() becomes blocked on anything that 78 requires the lower-priority interrupt, the system will hang. 79 80 For example, the thread that will perform the sema_v() may need to first 81 allocate memory. This memory allocation may require waiting for paging 82 I/O to complete, which may require a lower-priority disk or network 83 interrupt to be serviced. In general, situations like this are hard to 84 predict, so it is advisable to avoid waiting on semaphores or condition 85 variables in an interrupt context. 86 87 Similar to many other synchronization mechanisms, semaphores should not 88 be used in any code path that requires synchronization while handling 89 system panic, at which time many of the semaphore operations become no- 90 ops. 91 92 RETURN VALUES 93 0 sema_tryp() could not decrement the semaphore value because it 94 was zero. 95 96 1 sema_p_sig() was not able to decrement the semaphore value and 97 detected a pending signal. 98 99 SEE ALSO 100 kill(2), condvar(9F), mutex(9F) 101 102 Writing Device Drivers 103 104 illumos July 30, 2018 illumos