Manual Page Result
0
Command: pthread_cond | Section: 3 | Source: NetBSD | File: pthread_cond.3
PTHREAD_COND(3) FreeBSD Library Functions Manual PTHREAD_COND(3)
NAME
pthread_cond, pthread_cond_init, pthread_cond_destroy,
pthread_cond_broadcast, pthread_cond_signal, pthread_cond_wait,
pthread_cond_timedwait - condition variable interface
LIBRARY
POSIX Threads Library (libpthread, -lpthread)
SYNOPSIS
#include <pthread.h>
int
pthread_cond_init(pthread_cond_t * restrict cond,
const pthread_condattr_t * restrict attr);
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int
pthread_cond_destroy(pthread_cond_t *cond);
int
pthread_cond_broadcast(pthread_cond_t *cond);
int
pthread_cond_signal(pthread_cond_t *cond);
int
pthread_cond_wait(pthread_cond_t * restrict cond,
pthread_mutex_t * restrict mutex);
int
pthread_cond_timedwait(pthread_cond_t * restrict cond,
pthread_mutex_t * restrict mutex,
const struct timespec * restrict abstime);
DESCRIPTION
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 similar to calling pthread_cond_init()
with attr specified as NULL, except that no error checking 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 unblocks 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 determines 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 condition 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 functions. 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 spontaneously, 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 binding 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
different 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.
RETURN VALUES
If successful, all functions return zero. Otherwise, an error number
will be returned to indicate the error.
ERRORS
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.
SEE ALSO
pthread(3), pthread_barrier(3), pthread_condattr(3), pthread_mutex(3),
pthread_rwlock(3), pthread_spin(3)
STANDARDS
These functions conform to IEEE Std 1003.1-2001 ("POSIX.1").
FreeBSD 14.1-RELEASE-p8 July 8, 2010 FreeBSD 14.1-RELEASE-p8