Originální popis anglicky:
pthread_cond_broadcast, pthread_cond_signal - broadcast or signal a condition
Návod, kniha: POSIX Programmer's Manual
#include <pthread.h>
int pthread_cond_broadcast(pthread_cond_t *
cond);
int pthread_cond_signal(pthread_cond_t *
cond);
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.
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.
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.
None.
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.
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.
None.
pthread_cond_destroy() ,
pthread_cond_timedwait() , the Base
Definitions volume of IEEE Std 1003.1-2001,
<pthread.h>
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
.
