PTHREAD_COND_BROADCAST(3)  POSIX Programmer's Manual PTHREAD_COND_BROADCAST(3)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.

NNAAMMEE
       pthread_cond_broadcast, pthread_cond_signal -- broadcast or signal a
       condition

SSYYNNOOPPSSIISS
       #include <pthread.h>

       int pthread_cond_broadcast(pthread_cond_t *_c_o_n_d);
       int pthread_cond_signal(pthread_cond_t *_c_o_n_d);

DDEESSCCRRIIPPTTIIOONN
       These functions shall unblock threads blocked on a condition variable.

       The _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() function shall unblock all threads
       currently blocked on the specified condition variable _c_o_n_d.

       The _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() function shall unblock at least one of the
       threads that are blocked on the specified condition variable _c_o_n_d (if
       any threads are blocked on _c_o_n_d).

       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
       _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() or _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() returns from its call
       to _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() or _p_t_h_r_e_a_d___c_o_n_d___t_i_m_e_d_w_a_i_t(), the thread shall
       own the mutex with which it called _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() or
       _p_t_h_r_e_a_d___c_o_n_d___t_i_m_e_d_w_a_i_t().  The thread(s) that are unblocked shall
       contend for the mutex according to the scheduling policy (if
       applicable), and as if each had called _p_t_h_r_e_a_d___m_u_t_e_x___l_o_c_k().

       The _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() or _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() functions may be
       called by a thread whether or not it currently owns the mutex that
       threads calling _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() or _p_t_h_r_e_a_d___c_o_n_d___t_i_m_e_d_w_a_i_t() 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 _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() or
       _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l().

       The _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() and _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() functions shall
       have no effect if there are no threads currently blocked on _c_o_n_d.

       The behavior is undefined if the value specified by the _c_o_n_d argument
       to _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() or _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() does not refer to
       an initialized condition variable.

RREETTUURRNN VVAALLUUEE
       If successful, the _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() and _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l()
       functions shall return zero; otherwise, an error number shall be
       returned to indicate the error.

EERRRROORRSS
       These functions shall not return an error code of [[EEIINNTTRR]].

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
       None.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       The _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() 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
       _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() 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,
       _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() makes it easier to implement a read-write
       lock. The _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() 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 _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() 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
       _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() 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.

RRAATTIIOONNAALLEE
       If an implementation detects that the value specified by the _c_o_n_d
       argument to _p_t_h_r_e_a_d___c_o_n_d___b_r_o_a_d_c_a_s_t() or _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() does not
       refer to an initialized condition variable, it is recommended that the
       function should fail and report an [[EEIINNVVAALL]] error.

   MMuullttiippllee AAwwaakkeenniinnggss bbyy CCoonnddiittiioonn SSiiggnnaall
       On a multi-processor, it may be impossible for an implementation of
       _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l() to avoid the unblocking of more than one thread
       blocked on a condition variable. For example, consider the following
       partial implementation of _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() and
       _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l(), executed by two threads in the order given. One
       thread is trying to wait on the condition variable, another is
       concurrently executing _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l(), 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
       _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() or _p_t_h_r_e_a_d___c_o_n_d___t_i_m_e_d_w_a_i_t() as a result of one call
       to _p_t_h_r_e_a_d___c_o_n_d___s_i_g_n_a_l().  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 _p_t_h_r_e_a_d___c_o_n_d___w_a_i_t() 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, POSIX.1-2008 explicitly documents that
       spurious wakeups may occur.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _p_t_h_r_e_a_d___c_o_n_d___d_e_s_t_r_o_y(), _p_t_h_r_e_a_d___c_o_n_d___t_i_m_e_d_w_a_i_t()

       The Base Definitions volume of POSIX.1-2017, _S_e_c_t_i_o_n _4_._1_2, _M_e_m_o_r_y
       _S_y_n_c_h_r_o_n_i_z_a_t_i_o_n, <<pptthhrreeaadd..hh>>

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1-2017, Standard for Information Technology --
       Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, 2018 Edition, Copyright (C) 2018 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 .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2017            PTHREAD_COND_BROADCAST(3)
