1PTHREAD_COND_BROADCAST(3P) POSIX Programmer's ManualPTHREAD_COND_BROADCAST(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
13 pthread_cond_broadcast, pthread_cond_signal — broadcast or signal a
14 condition
15
17 #include <pthread.h>
18 int pthread_cond_broadcast(pthread_cond_t *cond);
20 int pthread_cond_signal(pthread_cond_t *cond);
21
23 These functions shall unblock threads blocked on a condition variable.
24 The pthread_cond_broadcast() function shall unblock all threads cur‐
26 rently blocked on the specified condition variable cond.
27 The pthread_cond_signal() function shall unblock at least one of the
29 threads that are blocked on the specified condition variable cond (if
30 any threads are blocked on cond).
31 If more than one thread is blocked on a condition variable, the sched‐
33 uling policy shall determine the order in which threads are unblocked.
34 When each thread unblocked as a result of a pthread_cond_broadcast() or
35 pthread_cond_signal() returns from its call to pthread_cond_wait() or
36 pthread_cond_timedwait(), the thread shall own the mutex with which it
37 called pthread_cond_wait() or pthread_cond_timedwait(). The thread(s)
38 that are unblocked shall contend for the mutex according to the sched‐
39 uling policy (if applicable), and as if each had called
40 pthread_mutex_lock().
41 The pthread_cond_broadcast() or pthread_cond_signal() functions may be
43 called by a thread whether or not it currently owns the mutex that
44 threads calling pthread_cond_wait() or pthread_cond_timedwait() have
45 associated with the condition variable during their waits; however, if
46 predictable scheduling behavior is required, then that mutex shall be
47 locked by the thread calling pthread_cond_broadcast() or
48 pthread_cond_signal().
49 The pthread_cond_broadcast() and pthread_cond_signal() functions shall
51 have no effect if there are no threads currently blocked on cond.
52 The behavior is undefined if the value specified by the cond argument
54 to pthread_cond_broadcast() or pthread_cond_signal() does not refer to
55 an initialized condition variable.
56
58 If successful, the pthread_cond_broadcast() and pthread_cond_signal()
59 functions shall return zero; otherwise, an error number shall be
60 returned to indicate the error.
61
63 These functions shall not return an error code of [EINTR].
64 The following sections are informative.
66
68 None.
69
71 The pthread_cond_broadcast() function is used whenever the shared-vari‐
72 able state has been changed in a way that more than one thread can pro‐
73 ceed with its task. Consider a single producer/multiple consumer prob‐
74 lem, where the producer can insert multiple items on a list that is
75 accessed one item at a time by the consumers. By calling the
76 pthread_cond_broadcast() function, the producer would notify all con‐
77 sumers that might be waiting, and thereby the application would receive
78 more throughput on a multi-processor. In addition, pthread_cond_broad‐
79 cast() makes it easier to implement a read-write lock. The
80 pthread_cond_broadcast() function is needed in order to wake up all
81 waiting readers when a writer releases its lock. Finally, the two-phase
82 commit algorithm can use this broadcast function to notify all clients
83 of an impending transaction commit.
84 It is not safe to use the pthread_cond_signal() function in a signal
86 handler that is invoked asynchronously. Even if it were safe, there
87 would still be a race between the test of the Boolean
88 pthread_cond_wait() that could not be efficiently eliminated.
89 Mutexes and condition variables are thus not suitable for releasing a
91 waiting thread by signaling from code running in a signal handler.
92
94 If an implementation detects that the value specified by the cond argu‐
95 ment to pthread_cond_broadcast() or pthread_cond_signal() does not
96 refer to an initialized condition variable, it is recommended that the
97 function should fail and report an [EINVAL] error.
98 Multiple Awakenings by Condition Signal
100 On a multi-processor, it may be impossible for an implementation of
101 pthread_cond_signal() to avoid the unblocking of more than one thread
102 blocked on a condition variable. For example, consider the following
103 partial implementation of pthread_cond_wait() and pthread_cond_sig‐
104 nal(), executed by two threads in the order given. One thread is trying
105 to wait on the condition variable, another is concurrently executing
106 pthread_cond_signal(), while a third thread is already waiting.
107 pthread_cond_wait(mutex, cond):
109 value = cond->value; /* 1 */
110 pthread_mutex_unlock(mutex); /* 2 */
111 pthread_mutex_lock(cond->mutex); /* 10 */
112 if (value == cond->value) { /* 11 */
113 me->next_cond = cond->waiter;
114 cond->waiter = me;
115 pthread_mutex_unlock(cond->mutex);
116 unable_to_run(me);
117 } else
118 pthread_mutex_unlock(cond->mutex); /* 12 */
119 pthread_mutex_lock(mutex); /* 13 */
120 pthread_cond_signal(cond):
122 pthread_mutex_lock(cond->mutex); /* 3 */
123 cond->value++; /* 4 */
124 if (cond->waiter) { /* 5 */
125 sleeper = cond->waiter; /* 6 */
126 cond->waiter = sleeper->next_cond; /* 7 */
127 able_to_run(sleeper); /* 8 */
128 }
129 pthread_mutex_unlock(cond->mutex); /* 9 */
130 The effect is that more than one thread can return from its call to
132 pthread_cond_wait() or pthread_cond_timedwait() as a result of one call
133 to pthread_cond_signal(). This effect is called ``spurious wakeup''.
134 Note that the situation is self-correcting in that the number of
135 threads that are so awakened is finite; for example, the next thread to
136 call pthread_cond_wait() after the sequence of events above blocks.
137 While this problem could be resolved, the loss of efficiency for a
139 fringe condition that occurs only rarely is unacceptable, especially
140 given that one has to check the predicate associated with a condition
141 variable anyway. Correcting this problem would unnecessarily reduce the
142 degree of concurrency in this basic building block for all higher-level
143 synchronization operations.
144 An added benefit of allowing spurious wakeups is that applications are
146 forced to code a predicate-testing-loop around the condition wait.
147 This also makes the application tolerate superfluous condition broad‐
148 casts or signals on the same condition variable that may be coded in
149 some other part of the application. The resulting applications are thus
150 more robust. Therefore, POSIX.1‐2008 explicitly documents that spurious
151 wakeups may occur.
152
154 None.
155
157 pthread_cond_destroy(), pthread_cond_timedwait()
158 The Base Definitions volume of POSIX.1‐2008, Section 4.11, Memory Syn‐
160 chronization, <pthread.h>
161
163 Portions of this text are reprinted and reproduced in electronic form
164 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
165 -- Portable Operating System Interface (POSIX), The Open Group Base
166 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
167 cal and Electronics Engineers, Inc and The Open Group. (This is
168 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
169 event of any discrepancy between this version and the original IEEE and
170 The Open Group Standard, the original IEEE and The Open Group Standard
171 is the referee document. The original Standard can be obtained online
172 at http://www.unix.org/online.html .
173 Any typographical or formatting errors that appear in this page are
175 most likely to have been introduced during the conversion of the source
176 files to man page format. To report such errors, see https://www.ker‐
177 nel.org/doc/man-pages/reporting_bugs.html .
178IEEE/The Open Group 2013 PTHREAD_COND_BROADCAST(3P)