.\" Copyright, the authors of the Linux man-pages project
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.TH pthread_cond_init 3 2025-05-17 "Linux man-pages (unreleased)"
.
.
.SH NAME
pthread_cond_init,
pthread_cond_signal,
pthread_cond_broadcast,
pthread_cond_wait,
pthread_cond_timedwait,
pthread_cond_destroy
\-
operations on conditions
.
.
.SH SYNOPSIS
.nf
.B #include <pthread.h>
.P
.BI "pthread_cond_t " cond " = PTHREAD_COND_INITIALIZER;"
.P
.BI "int pthread_cond_init(pthread_cond_t *" cond ,
.BI "                      pthread_condattr_t *" cond_attr );
.BI "int pthread_cond_signal(pthread_cond_t *" cond );
.BI "int pthread_cond_broadcast(pthread_cond_t *" cond );
.BI "int pthread_cond_wait(pthread_cond_t *" cond ", pthread_mutex_t *" mutex );
.BI "int pthread_cond_timedwait(pthread_cond_t *" cond ", pthread_mutex_t *" mutex ,
.BI "                      const struct timespec *" abstime );
.BI "int pthread_cond_destroy(pthread_cond_t *" cond );
.fi
.
.
.SH DESCRIPTION
A condition (short for "condition variable")
is a synchronization device that allows threads
to suspend execution and relinquish the processors
until some predicate on shared data is satisfied.
The basic operations on conditions are:
signal the condition (when the predicate becomes true),
and wait for the condition,
suspending the thread execution until another thread signals the condition.
.P
A condition variable must always be associated with a mutex,
to avoid the race condition where
a thread prepares to wait on a condition variable
and another thread signals the condition
just before the first thread actually waits on it.
.P
.BR pthread_cond_init ()
initializes the condition variable
.IR cond ,
using the condition attributes specified in
.IR cond_attr ,
or default attributes if
.I cond_attr
is NULL.
The LinuxThreads implementation supports no attributes for conditions,
hence the
.I cond_attr
parameter is actually ignored.
.P
Variables of type
.I pthread_cond_t
can also be initialized statically,
using the constant
.BR PTHREAD_COND_INITIALIZER .
.P
.BR pthread_cond_signal ()
restarts one of the threads that
are waiting on the condition variable
.IR cond .
If no threads are waiting on
.IR cond ,
nothing happens.
If several threads are waiting on
.IR cond ,
exactly one is restarted,
but it is not specified which.
.P
.BR pthread_cond_broadcast ()
restarts all the threads that
are waiting on the condition variable
.IR cond .
Nothing happens if no threads are waiting on
.IR cond .
.P
.BR pthread_cond_wait ()
atomically unlocks the
.I mutex
(as per
.BR pthread_unlock_mutex ())
and waits for the condition variable
.I cond
to be signaled.
The thread execution is suspended and does not consume any CPU time
until the condition variable is signaled.
The
.I mutex
must be locked by the calling thread
on entrance to
.BR pthread_cond_wait ().
Before returning to the calling thread,
.BR pthread_cond_wait ()
re-acquires
.I mutex
(as per
.BR pthread_mutex_lock ()).
.P
Unlocking the mutex and suspending on the condition variable is done atomically.
Thus,
if all threads always acquire the mutex before signaling the condition,
this guarantees that the condition cannot be signaled (and thus ignored)
between the time a thread locks the mutex
and the time it waits on the condition variable.
.P
.BR pthread_cond_timedwait ()
atomically unlocks
.I mutex
and waits on
.IR cond ,
as
.BR pthread_cond_wait ()
does,
but it also bounds the duration of the wait.
If
.I cond
has not been signaled
within the amount of time specified by
.IR abstime ,
the mutex
.I mutex
is re-acquired
and
.BR pthread_cond_timedwait ()
returns the error
.BR ETIMEDOUT .
The
.I abstime
parameter specifies an absolute time,
with the same origin as
.BR time (2)
and
.BR gettimeofday (2):
an
.I abstime
of 0
corresponds to 00:00:00 GMT, January 1, 1970.
.P
.BR pthread_cond_destroy ()
destroys a condition variable,
freeing the resources it might hold.
No threads must be waiting on the condition variable
on entrance to
.BR pthread_cond_destroy ().
In the LinuxThreads implementation,
no resources are associated with condition variables,
thus
.BR pthread_cond_destroy ()
actually does nothing
except checking that the condition has no waiting threads.
.
.
.SH CANCELLATION
.BR pthread_cond_wait ()
and
.BR pthread_cond_timedwait ()
are cancelation points.
If a thread is cancelled while suspended in one of these functions,
the thread immediately resumes execution,
then locks again the
.I mutex
argument to
.BR pthread_cond_wait ()
and
.BR pthread_cond_timedwait (),
and finally executes the cancelation.
Consequently,
cleanup handlers are assured that
.I mutex
is locked
when they are called.
.
.
.SH "ASYNC-SIGNAL SAFETY"
The condition functions are not async-signal safe,
and should not be called from a signal handler.
In particular,
calling
.BR pthread_cond_signal ()
or
.BR pthread_cond_broadcast ()
from a signal handler
may deadlock the calling thread.
.
.
.SH "RETURN VALUE"
All condition variable functions return 0 on success
and a non-zero error code on error.
.
.
.SH ERRORS
.BR pthread_cond_init (),
.BR pthread_cond_signal (),
.BR pthread_cond_broadcast (),
and
.BR pthread_cond_wait ()
never return an error code.
.P
The
.BR pthread_cond_timedwait ()
function returns
the following error codes on error:
.RS
.TP
.B ETIMEDOUT
The condition variable was not signaled
until the timeout specified by
.I abstime .
.RE
.P
The
.BR pthread_cond_destroy ()
function returns
the following error code on error:
.RS
.TP
.B EBUSY
Some threads are currently waiting on
.I cond .
.RE
.
.
.SH "SEE ALSO"
.BR pthread_condattr_init (3),
.BR pthread_mutex_lock (3),
.BR pthread_mutex_unlock (3),
.BR gettimeofday (2),
.BR nanosleep (2).
.
.
.SH EXAMPLE
Consider two shared variables
.I x
and
.I y ,
protected by the mutex
.IR mut ,
and a condition variable
.I cond
that is to be signaled
whenever
.I x
becomes greater than
.IR y .
.P
.RS
.ft 3
.nf
.sp
int x,y;
pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
.ft
.RE
.fi
.P
Waiting until
.I x
is greater than
.I y
is performed as follows:
.P
.RS
.ft 3
.nf
.sp
pthread_mutex_lock(&mut);
while (x <= y) {
        pthread_cond_wait(&cond, &mut);
}
/* operate on x and y */
pthread_mutex_unlock(&mut);
.ft
.RE
.fi
.P
Modifications on
.I x
and
.I y
that may cause
.I x
to become greater than
.I y
should signal the condition if needed:
.P
.RS
.ft 3
.nf
.sp
pthread_mutex_lock(&mut);
/* modify x and y */
if (x > y) pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&mut);
.ft
.RE
.fi
.P
If it can be proved that at most one waiting thread needs to be waken up
(for instance,
if there are only two threads communicating through
.I x
and
.IR y ),
.BR pthread_cond_signal ()
can be used as
a slightly more efficient alternative to
.BR pthread_cond_broadcast ().
In doubt,
use
.BR pthread_cond_broadcast ().
.P
To wait for
.I x
to become greater than
.I y
with a timeout of 5 seconds,
do:
.P
.RS
.ft 3
.nf
.sp
struct timeval now;
struct timespec timeout;
int retcode;
\&
pthread_mutex_lock(&mut);
gettimeofday(&now);
timeout.tv_sec = now.tv_sec + 5;
timeout.tv_nsec = now.tv_usec * 1000;
retcode = 0;
while (x <= y && retcode != ETIMEDOUT) {
        retcode = pthread_cond_timedwait(&cond, &mut, &timeout);
}
if (retcode == ETIMEDOUT) {
        /* timeout occurred */
} else {
        /* operate on x and y */
}
pthread_mutex_unlock(&mut);
.ft
.RE
.fi