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