pthread_cond_broadcast(3p) — Linux manual page

PROLOG | NAME | SYNOPSIS | DESCRIPTION | RETURN VALUE | ERRORS | EXAMPLES | APPLICATION USAGE | RATIONALE | FUTURE DIRECTIONS | SEE ALSO | COPYRIGHT

PTHREAD_...ROADCAST(3P) POSIX Programmer's ManualPTHREAD_...ROADCAST(3P)

PROLOG         top

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

NAME         top

       pthread_cond_broadcast, pthread_cond_signal — broadcast or signal
       a condition

SYNOPSIS         top

       #include <pthread.h>

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

DESCRIPTION         top

       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.

       The behavior is undefined if the value specified by the cond
       argument to pthread_cond_broadcast() or pthread_cond_signal()
       does not refer to an initialized condition variable.

RETURN VALUE         top

       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.

ERRORS         top

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

       The following sections are informative.

EXAMPLES         top

       None.

APPLICATION USAGE         top

       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.

RATIONALE         top

       If an implementation detects that the value specified by the cond
       argument to pthread_cond_broadcast() or pthread_cond_signal()
       does not refer to an initialized condition variable, it is
       recommended that the function should fail and report an [EINVAL]
       error.

   Multiple Awakenings by Condition Signal
       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,
       POSIX.1‐2008 explicitly documents that spurious wakeups may
       occur.

FUTURE DIRECTIONS         top

       None.

SEE ALSO         top

       pthread_cond_destroy(3p), pthread_cond_timedwait(3p)

       The Base Definitions volume of POSIX.1‐2017, Section 4.12, Memory
       Synchronization, pthread.h(0p)

COPYRIGHT         top

       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_...ROADCAST(3P)

Pages that refer to this page: pthread.h(0p)pthread_cond_destroy(3p)pthread_cond_signal(3p)pthread_cond_timedwait(3p)