Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

NetBSD 6.1.5 - man page for pthread_cond_signal (netbsd section 3)

PTHREAD_COND(3) 		   BSD Library Functions Manual 		  PTHREAD_COND(3)

     pthread_cond -- condition variable interface

     POSIX Threads Library (libpthread, -lpthread)

     #include <pthread.h>

     pthread_cond_init(pthread_cond_t * restrict cond, const pthread_condattr_t * restrict attr);

     pthread_cond_destroy(pthread_cond_t *cond);

     pthread_cond_broadcast(pthread_cond_t *cond);

     pthread_cond_signal(pthread_cond_t *cond);

     pthread_cond_wait(pthread_cond_t * restrict cond, pthread_mutex_t * restrict mutex);

     pthread_cond_timedwait(pthread_cond_t * restrict cond, pthread_mutex_t * restrict mutex,
	 const struct timespec * restrict abstime);

     pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

     Condition variables are intended to be used to communicate changes in the state of data
     shared between threads.  Condition variables are always associated with a mutex to provide
     synchronized access to the shared data.  A single predicate should always be associated with
     a condition variable.  The predicate should identify a state of the shared data that must be
     true before the thread proceeds.

     The pthread_cond_init() function creates a new condition variable, with attributes specified
     with attr.  If attr is NULL the default attributes are used.  The pthread_cond_destroy()
     function frees the resources allocated by the condition variable cond.

     The macro PTHREAD_COND_INITIALIZER can be used to initialize a condition variable when it
     can be statically allocated and the default attributes are appropriate.  The effect is simi-
     lar to calling pthread_cond_init() with attr specified as NULL, except that no error check-
     ing is done.

     The difference between pthread_cond_broadcast() and pthread_cond_signal() is that the former
     unblocks all threads waiting for the condition variable, whereas the latter blocks only one
     waiting thread.  If no threads are waiting on cond, neither function has any effect.  If
     more than one thread is blocked on a condition variable, the used scheduling policy deter-
     mines the order in which threads are unblocked.  The same mutex used for waiting must be
     held while calling either function.  Although neither function strictly enforces this
     requirement, undefined behavior may follow if the mutex is not held.

     The pthread_cond_wait() function atomically blocks the current thread waiting on the condi-
     tion variable specified by cond, and unlocks the mutex specified by mutex.  The
     pthread_cond_timedwait() function behaves similarly, but unblocks also if the system time
     reaches the time specified in abstime, represented as struct timespec (see timespec(3)).
     With both functions the waiting thread unblocks after another thread calls
     pthread_cond_signal() or pthread_cond_broadcast() with the same condition variable and by
     holding the same mutex that was associated with cond by either one of the blocking func-
     tions.  The current thread holds the lock on mutex upon return from either function.

     Note that a call to pthread_cond_wait() or pthread_cond_timedwait() may wake up sponta-
     neously, without a call to pthread_cond_signal() or pthread_cond_broadcast().  The caller
     should prepare for this by invoking either function within a predicate loop that tests
     whether the thread should proceed.

     As noted, when calling either function that waits on a condition variable, a temporary bind-
     ing is established between the condition variable cond and the mutex mutex.  During this
     time, the effect of an attempt by any thread to wait on that condition variable using a dif-
     ferent mutex is undefined.  The same mutex must be held while broadcasting or signaling on
     cond.  Additionally, the same mutex must be used for concurrent calls to pthread_cond_wait()
     and pthread_cond_timedwait().  Only when a condition variable is known to be quiescent may
     an application change the mutex associated with it.  In this implementation, none of the
     functions enforce this requirement, but if the mutex is not held or independent mutexes are
     used the resulting behaviour is undefined.

     If successful, all functions return zero.	Otherwise, an error number will be returned to
     indicate the error.

     The pthread_cond_init() function may fail if:

     [EINVAL]		The value specified by attr is invalid.

     The pthread_cond_destroy() function may fail if:

     [EBUSY]		The variable cond is locked by another thread.

     [EINVAL]		The value specified by cond is invalid.

     Both pthread_cond_broadcast() and pthread_cond_signal() may fail if:

     [EINVAL]		The value specified by cond is invalid.

     Both pthread_cond_wait() and pthread_cond_timedwait() may fail if:

     [EINVAL]		The value specified by cond or the value specified by mutex is invalid.

     [EPERM]		The value specified by mutex was not locked in the condition wait.

     The pthread_cond_timedwait() function may additionally fail if:

     [ETIMEDOUT]	The system time has reached or exceeded the time specified in abstime.

     pthread(3), pthread_barrier(3), pthread_condattr(3), pthread_mutex(3), pthread_rwlock(3),

     These functions conform to IEEE Std 1003.1-2001 (``POSIX.1'').

BSD					   July 8, 2010 				      BSD

All times are GMT -4. The time now is 04:15 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password