Print this page
9249 System crash dump to NVME not working
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
Reviewed by: Evan Layton <evan.layton@nexenta.com>
Reviewed by: Rick McNeal <rick.mcneal@nexenta.com>
Reviewed by: Ryan Zezeski <rpz@joyent.com>
   1 SEMAPHORE(9F)            Kernel Functions for Drivers            SEMAPHORE(9F)
   2 
   3 
   4 
   5 NAME
   6        semaphore, sema_init, sema_destroy, sema_p, sema_p_sig, sema_v,
   7        sema_tryp - semaphore functions
   8 
   9 SYNOPSIS
  10        #include <sys/ksynch.h>
  11 
  12 
  13 
  14        void sema_init(ksema_t *sp, uint_t val, char *name, ksema_type_t type,
  15              void *arg);
  16 


  17 
  18        void sema_destroy(ksema_t *sp);

  19 


  20 
  21        void sema_p(ksema_t *sp);

  22 


  23 
  24        void sema_v(ksema_t *sp);
  25 
  26 
  27        int sema_p_sig(ksema_t *sp);
  28 
  29 
  30        int sema_tryp(ksema_t *sp);
  31 
  32 
  33 INTERFACE LEVEL
  34        Solaris DDI specific (Solaris DDI).
  35 
  36 PARAMETERS
  37        sp
  38                A pointer to a semaphore, type ksema_t.
  39 

  40 
  41        val
  42                Initial value for semaphore.
  43 
  44 
  45        name
  46                Descriptive string. This is obsolete and should be NULL.
  47                (Non-NULL strings are legal, but they are a waste of kernel
  48                memory.)
  49 
  50 
  51        type
  52                Variant type of the semaphore. Currently, only SEMA_DRIVER is
  53                supported.
  54 

  55 
  56        arg
  57                Type-specific argument; should be NULL.
  58 
  59 
  60 DESCRIPTION
  61        These functions implement counting semaphores as described by Dijkstra.
  62        A semaphore has a value which is atomically decremented by sema_p() and
  63        atomically incremented by sema_v(). The value must always be greater
  64        than or equal to zero. If sema_p() is called and the value is zero, the
  65        calling thread is blocked until another thread performs a sema_v()
  66        operation on the semaphore.
  67 
  68 
  69        Semaphores are initialized by calling sema_init(). The argument, val,
  70        gives the initial value for the semaphore. The semaphore storage is
  71        provided by the caller but more may be dynamically allocated, if
  72        necessary, by sema_init(). For this reason, sema_destroy() should be
  73        called before deallocating the storage containing the semaphore.
  74 
  75 
  76        The sema_p_sig() function decrements the semaphore, as does sema_p().
  77        However, if the semaphore value is zero, sema_p_sig() will return
  78        without decrementing the value if a signal (that is, from kill(2)) is
  79        pending for the thread.
  80 


  81 
  82        The sema_tryp() function will decrement the semaphore value only if it
  83        is greater than zero, and will not block.
  84 
  85 RETURN VALUES
  86        0
  87             sema_tryp() could not decrement the semaphore value because it was
  88             zero.
  89 
  90 
  91        1
  92             sema_p_sig() was not able to decrement the semaphore value and
  93             detected a pending signal.
  94 
  95 
  96 CONTEXT
  97        These functions can be called from user, interrupt, or kernel context,
  98        except for sema_init() and sema_destroy(), which can be called from
  99        user or kernel context only. None of these functions can be called from
 100        a high-level interrupt context. In most cases, sema_v() and sema_p()
 101        should not be called from any interrupt context.
 102 
 103 
 104        If sema_p() is used from interrupt context, lower-priority interrupts
 105        will not be serviced during the wait. This means that if the thread
 106        that will eventually perform the sema_v() becomes blocked on anything
 107        that requires the lower-priority interrupt, the system will hang.
 108 






 109 
 110        For example, the thread that will perform the sema_v() may need to
 111        first allocate memory. This memory allocation may require waiting for
 112        paging I/O to complete, which may require a lower-priority disk or
 113        network interrupt to be serviced. In general, situations like this are
 114        hard to predict, so it is advisable to avoid waiting on semaphores or
 115        condition variables in an interrupt context.
 116 







 117 SEE ALSO
 118        kill(2), condvar(9F), mutex(9F)
 119 
 120 
 121        Writing Device Drivers
 122 
 123 
 124 
 125                                   May 7, 1997                    SEMAPHORE(9F)
   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