NAME
pthread_cond_broadcast, pthread_cond_signal - broadcast or signal a
condition
SYNOPSIS
#include <pthread.h>
int pthread_cond_broadcast(pthread_cond_t *cond);
int pthread_cond_signal(pthread_cond_t *cond);
DESCRIPTION
These functions shall unblock threads blocked on a condition variable.
The pthread_cond_broadcast() function shall unblock all threads
currently blocked on the specified condition variable cond.
The pthread_cond_signal() function shall unblock at least one of the
threads that are blocked on the specified condition variable cond (if
any threads are blocked on cond).
If more than one thread is blocked on a condition variable, the
scheduling policy shall determine the order in which threads are
unblocked. When each thread unblocked as a result of a
pthread_cond_broadcast() or pthread_cond_signal() returns from its call
to pthread_cond_wait() or pthread_cond_timedwait(), the thread shall
own the mutex with which it called pthread_cond_wait() or
pthread_cond_timedwait(). The thread(s) that are unblocked shall
contend for the mutex according to the scheduling policy (if
applicable), and as if each had called pthread_mutex_lock().
The pthread_cond_broadcast() or pthread_cond_signal() functions may be
called by a thread whether or not it currently owns the mutex that
threads calling pthread_cond_wait() or pthread_cond_timedwait() have
associated with the condition variable during their waits; however, if
predictable scheduling behavior is required, then that mutex shall be
locked by the thread calling pthread_cond_broadcast() or
pthread_cond_signal().
The pthread_cond_broadcast() and pthread_cond_signal() functions shall
have no effect if there are no threads currently blocked on cond.
RETURN VALUE
If successful, the pthread_cond_broadcast() and pthread_cond_signal()
functions shall return zero; otherwise, an error number shall be
returned to indicate the error.
ERRORS
The pthread_cond_broadcast() and pthread_cond_signal() function may
fail if:
EINVAL The value cond does not refer to an initialized condition
variable.
These functions shall not return an error code of [EINTR].
The following sections are informative.
EXAMPLES
None.
APPLICATION USAGE
The pthread_cond_broadcast() function is used whenever the shared-
variable state has been changed in a way that more than one thread can
proceed with its task. Consider a single producer/multiple consumer
problem, where the producer can insert multiple items on a list that is
accessed one item at a time by the consumers. By calling the
pthread_cond_broadcast() function, the producer would notify all
consumers that might be waiting, and thereby the application would
receive more throughput on a multi-processor. In addition,
pthread_cond_broadcast() makes it easier to implement a read-write
lock. The pthread_cond_broadcast() function is needed in order to wake
up all waiting readers when a writer releases its lock. Finally, the
two-phase commit algorithm can use this broadcast function to notify
all clients of an impending transaction commit.
It is not safe to use the pthread_cond_signal() function in a signal
handler that is invoked asynchronously. Even if it were safe, there
would still be a race between the test of the Boolean
pthread_cond_wait() that could not be efficiently eliminated.
Mutexes and condition variables are thus not suitable for releasing a
waiting thread by signaling from code running in a signal handler.
RATIONALE
Multiple Awakenings by Condition Signal
On a multi-processor, it may be impossible for an implementation of
pthread_cond_signal() to avoid the unblocking of more than one thread
blocked on a condition variable. For example, consider the following
partial implementation of pthread_cond_wait() and
pthread_cond_signal(), executed by two threads in the order given. One
thread is trying to wait on the condition variable, another is
concurrently executing pthread_cond_signal(), while a third thread is
already waiting.
pthread_cond_wait(mutex, cond):
value = cond->value; /* 1 */
pthread_mutex_unlock(mutex); /* 2 */
pthread_mutex_lock(cond->mutex); /* 10 */
if (value == cond->value) { /* 11 */
me->next_cond = cond->waiter;
cond->waiter = me;
pthread_mutex_unlock(cond->mutex);
unable_to_run(me);
} else
pthread_mutex_unlock(cond->mutex); /* 12 */
pthread_mutex_lock(mutex); /* 13 */
pthread_cond_signal(cond):
pthread_mutex_lock(cond->mutex); /* 3 */
cond->value++; /* 4 */
if (cond->waiter) { /* 5 */
sleeper = cond->waiter; /* 6 */
cond->waiter = sleeper->next_cond; /* 7 */
able_to_run(sleeper); /* 8 */
}
pthread_mutex_unlock(cond->mutex); /* 9 */
The effect is that more than one thread can return from its call to
pthread_cond_wait() or pthread_cond_timedwait() as a result of one call
to pthread_cond_signal(). This effect is called "spurious wakeup".
Note that the situation is self-correcting in that the number of
threads that are so awakened is finite; for example, the next thread to
call pthread_cond_wait() after the sequence of events above blocks.
While this problem could be resolved, the loss of efficiency for a
fringe condition that occurs only rarely is unacceptable, especially
given that one has to check the predicate associated with a condition
variable anyway. Correcting this problem would unnecessarily reduce the
degree of concurrency in this basic building block for all higher-level
synchronization operations.
An added benefit of allowing spurious wakeups is that applications are
forced to code a predicate-testing-loop around the condition wait. This
also makes the application tolerate superfluous condition broadcasts or
signals on the same condition variable that may be coded in some other
part of the application. The resulting applications are thus more
robust. Therefore, IEEE Std 1003.1-2001 explicitly documents that
spurious wakeups may occur.
FUTURE DIRECTIONS
None.
SEE ALSO
pthread_cond_destroy() , pthread_cond_timedwait() , the Base
Definitions volume of IEEE Std 1003.1-2001, <pthread.h>
COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group. In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online
at http://www.opengroup.org/unix/online.html .