1PTHREAD_COND_BROADCAST(3P) POSIX Programmer's ManualPTHREAD_COND_BROADCAST(3P)
2
3
4

PROLOG

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
11

NAME

13       pthread_cond_broadcast, pthread_cond_signal —  broadcast  or  signal  a
14       condition
15

SYNOPSIS

17       #include <pthread.h>
18
19       int pthread_cond_broadcast(pthread_cond_t *cond);
20       int pthread_cond_signal(pthread_cond_t *cond);
21

DESCRIPTION

23       These functions shall unblock threads blocked on a condition variable.
24
25       The  pthread_cond_broadcast()  function  shall unblock all threads cur‐
26       rently blocked on the specified condition variable cond.
27
28       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
32       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
42       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
50       The pthread_cond_broadcast() and pthread_cond_signal() functions  shall
51       have no effect if there are no threads currently blocked on cond.
52
53       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

RETURN VALUE

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

ERRORS

63       These functions shall not return an error code of [EINTR].
64
65       The following sections are informative.
66

EXAMPLES

68       None.
69

APPLICATION USAGE

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
85       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
90       Mutexes and condition variables are thus not suitable for  releasing  a
91       waiting thread by signaling from code running in a signal handler.
92

RATIONALE

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
99   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
108           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
121           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
131       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
138       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
145       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

FUTURE DIRECTIONS

154       None.
155

SEE ALSO

157       pthread_cond_destroy(), pthread_cond_timedwait()
158
159       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
174       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 .
178
179
180
181IEEE/The Open Group                  2013           PTHREAD_COND_BROADCAST(3P)
Impressum