PTHREAD_COND_BROADCAST(3P)

💖 PTHREAD_COND_BROADCAST(3P) — the POSIX Programmer's Manual, bestie edition 💖

okay so real quick before we get into it — this page lives in the POSIX Programmer's Manual, and the PROLOG has something important to say:

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.

so like, it's giving "spec, not receipt" — check your actual platform before you commit, bestie 🫶

---

✨ NAME ✨

pthread_cond_broadcast, pthread_cond_signal — broadcast or signal a condition 💅

---

🌸 SYNOPSIS 🌸

#include <pthread.h>

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

---

🦋 DESCRIPTION 🦋

So. These functions shall unblock threads blocked on a condition variable. That's the whole vibe. 🌈

• pthread_cond_broadcast() shall unblock all threads currently blocked on the specified condition variable cond. everybody up, no one left behind, periodt 👑
• pthread_cond_signal() shall unblock at least one of the threads that are blocked on the specified condition variable cond — if any threads are blocked on cond. (and if nobody's there? we'll get to that.)

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(). so yeah, they're fighting for the mutex like it's the last seat at the lunch table 😭

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(). iykyk 🎀

The pthread_cond_broadcast() and pthread_cond_signal() functions shall have no effect if there are no threads currently blocked on cond. literally yelling into the void, and the void is fine with it 💀

⚠️ 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. undefined behavior, bestie. we don't do that. 🙈

---

💜 RETURN VALUE 💜

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. so 0 = slay, anything else = read the number 🫶

---

🍓 ERRORS 🍓

These functions shall not return an error code of [EINTR]. not on the menu, never was. ✨

The following sections are informative.

---

🧚 EXAMPLES 🧚

None. (yes, literally. the manpage said "None." and we're respecting it 💅)

---

🌸 APPLICATION USAGE 🌸

pthread_cond_broadcast() 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. iconic honestly 💖

🚨 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.

So: mutexes and condition variables are thus not suitable for releasing a waiting thread by signaling from code running in a signal handler. noted, bestie. no signal-handler shenanigans. 💀

---

🔥 RATIONALE 🔥

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. so like, it's a feature not a bug, lowkey 🦋

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. periodt. 💅

---

🌈 FUTURE DIRECTIONS 🌈

None. (nothing on the horizon, we're chilling ✨)

---

🎀 SEE ALSO 🎀

• pthread_cond_destroy()
• pthread_cond_timedwait()

The Base Definitions volume of POSIX.1‐2017, Section 4.12, Memory Synchronization, <pthread.h> 📖

---

💜 COPYRIGHT 💜

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 .

---

and that's the whole page bestie 💖 this one came straight from IEEE/The Open Group, dated 2017 — go forth and broadcast responsibly, mwah 🎀✨