snd_bug_on(9) [suse man page]

SND_BUG_ON(9)							   Sound Devices						     SND_BUG_ON(9)

NAME

       snd_BUG_ON - debugging check macro

SYNOPSIS

       snd_BUG_ON(cond);

ARGUMENTS

       cond
	   condition to evaluate

DESCRIPTION

       When CONFIG_SND_DEBUG is set, this macro evaluates the given condition, and call WARN and returns the value if it's non-zero.

       When CONFIG_SND_DEBUG is not set, this just returns zero, and the given condition is ignored.

NOTE

       the argument won't be evaluated at all when CONFIG_SND_DEBUG=n. Thus, don't put any statement that influences on the code behavior, such as
       pre/post increment, to the argument of this macro. If you want to evaluate and give a warning, use standard WARN_ON.

COPYRIGHT

Kernel Hackers Manual 2.6.					     July 2010							     SND_BUG_ON(9)

pthread_cond_signal(3T) 												   pthread_cond_signal(3T)

NAME

       pthread_cond_signal(), pthread_cond_broadcast() - unblock one or all threads waiting on a condition variable

SYNOPSIS

PARAMETERS

	      cond	Pointer to the condition variable to be signaled or broadcast.

DESCRIPTION

       The  function  is  used to wake-up one of the threads that are waiting for the occurrence of a condition associated with condition variable
       cond.  If there are no threads blocked on cond, this function has no effect.  If more than one thread is blocked on  cond,  the	scheduling
       policy determines which thread is unblocked.  It is possible that more than one thread can be unblocked due to a spurious wakeup.

       The function is used to wake-up all threads that are waiting for the occurrence of a condition associated with the condition variable cond.
       If there are no threads blocked on cond, this function has no effect.  If more than one thread is blocked on cond,  the	scheduling  policy
       determines the order in which threads are unblocked.

       The condition variabled denoted by cond must have been dynamically initialized by a call to or statically initialized with the macro

       An  unblocked  thread  will  reacquire  the  mutex it held when it started the condition wait before returning from or The threads that are
       unblocked contend for the mutex according to their scheduling policy and priority.

       The or functions can be called by a thread whether or not it currently owns the condition variable's  associated  mutex.   For  predictable
       scheduling behavior and to prevent lost wake-ups, the mutex should be held when signaling a condition variable.

   Usage
       When  using  condition variables, there is a boolean predicate associated with each condition wait.  If this predicate is false, the thread
       should do a condition wait.  Spurious wakeups may occur when waiting on a condition variable.  Because the return values from  and  do  not
       imply anything about the value of this predicate, the predicate should always be re-evaluated.

       Applications  using  condition  variables typically acquire a mutex and enter a loop which checks the predicate.  Depending on the value of
       the predicate, the thread either breaks out of the loop or waits on the condition.  On return from the condition wait, the predicate is re-
       evaluated.

RETURN VALUE

       Upon successful completion, and return zero. Otherwise, an error number is returned to indicate the error (the variable is not set).

ERRORS

       For each of the following conditions, if the condition is detected, the and functions return the corresponding error number:

	      [EINVAL]	     cond is not a valid condition variable.

	      [EFAULT]	     cond parameter points to an illegal address.

AUTHOR

       and were derived from the IEEE POSIX P1003.1c standard.

SEE ALSO

       pthread_cond_init(3T), pthread_cond_wait(3T).

STANDARDS CONFORMANCE

								  Pthread Library					   pthread_cond_signal(3T)