Description

   This routine wakes one thread waiting on a condition variable.
   It can only be called from a software interrupt handler routine.
   Calling this routine implies that it might be possible for a
   single waiting thread to proceed. Call this routine when any
   thread waiting on the specified condition variable might find its
   predicate true.

   The scheduling policies of the waiting threads determine which
   thread is awakened. For policies SCHED_FIFO and SCHED_RR, a
   blocked thread is chosen in priority order, using first-in/first-
   out (FIFO) within priorities.

   You can call this routine when the associated mutex is either
   locked or unlocked. (Never try to lock a mutex from an interrupt
   handler.)

   This routine allows you to signal a thread from a software
   interrupt handler. Do not call this routine from noninterrupt
   code. If you want to signal a thread from the normal noninterrupt
   level, use pthread_cond_signal.

                                  NOTE

      If a waiting thread has a preemptive scheduling policy and
      a higher priority than the thread which was running when
      the interrupt occurred, then the waiting thread will preempt
      the interrupt routine and begin to run immediately. This
      is unlike pthread_cond_signal_int_np() which causes the
      condition variable to be signaled at a safe point after
      the interrupt has completed. pthread_cond_sig_preempt_int_
      np() avoids the possible latency which pthread_cond_signal_
      int_np() may introduce; however, a side effect of this is
      that during the call to pthread_cond_sig_preempt_int_np()
      other threads may run if a preemption occurs. Thus, once an
      interrupt routine calls pthread_cond_sig_preempt_int_np()
      it can no longer rely on any assumptions of exclusivity
      or atomicity which are typically provided by interrupt
      routines. Furthermore, once the call to pthread_cond_sig_
      preempt_int_np() is made, in addition to other threads
      running, subsequent interrupts may be delivered at any time
      as well (that is, they will not be blocked until the current
      interrupt completes). For this reason, it is recommended
      that pthread_cond_sig_preempt_int_np() be called as the last
      statement in the interrupt routine.