PTHREAD...ER_WAIT(3POSIX)

πŸ’– PTHREAD_BARRIER_WAIT(3POSIX) πŸ’–

okay bestie, so this page is from the POSIX Programmer's Manual (the 3POSIX section, we love a standards girlie) ✨

Heads up before we even start: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so go check the corresponding Linux manual page for the tea on Linux behavior), or honestly the interface might not even be implemented on Linux at all. πŸ™ˆ

🌸 NAME 🌸

pthread_barrier_wait β€” synchronize at a barrier


✨ SYNOPSIS ✨

#include <pthread.h>

int pthread_barrier_wait(pthread_barrier_t *barrier);

πŸŽ€ DESCRIPTION πŸŽ€

So pthread_barrier_wait() synchronizes all the participating threads at the barrier that barrier points to. The calling thread just blocks β€” like, sits there, patiently, main character waiting at the bus stop β€” until the required number of threads have called pthread_barrier_wait() specifying that same barrier. πŸ¦‹

Once the required number of threads have called pthread_barrier_wait() on that barrier, the constant PTHREAD_BARRIER_SERIAL_THREAD shall be returned to one unspecified thread, and zero gets returned to each of the remaining threads. And at that point? The barrier shall be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it. So it's a fresh start, no baggage, we love a reset era. πŸ’…

The constant PTHREAD_BARRIER_SERIAL_THREAD is defined in <pthread.h>, and its value shall be distinct from any other value returned by pthread_barrier_wait(). So it's giving unique, one of one, no dupes. πŸ‘‘

⚠️ The results are undefined if this function is called with an uninitialized barrier. Like, do not. That's not a vibe, that's chaos. πŸ’€

Now, if a signal is delivered to a thread that's blocked on a barrier: upon return from the signal handler, the thread shall resume waiting at the barrier if the barrier wait has not completed (that is, if the required number of threads have not arrived at the barrier during the execution of the signal handler). Otherwise β€” if it did complete β€” the thread shall just continue as normal from the completed barrier wait. And until that thread in the signal handler returns from it, it is unspecified whether other threads may proceed past the barrier once they have all reached it. 🫢

A thread that has blocked on a barrier shall not prevent any unblocked thread that is eligible to use the same processing resources from eventually making forward progress in its execution. Eligibility for processing resources shall be determined by the scheduling policy. (Translation: no thread is allowed to be a resource hog and block the group chat. Be respectful.) 😭


πŸ”₯ RETURN VALUE πŸ”₯

Upon successful completion, the pthread_barrier_wait() function shall return PTHREAD_BARRIER_SERIAL_THREAD for a single (arbitrary) thread synchronized at the barrier, and zero for each of the other threads. 🌈

Otherwise? An error number shall be returned to indicate the error. Yep, that's the whole vibe.


πŸ’œ ERRORS πŸ’œ

This function shall not return an error code of [EINTR]. Periodt.

The following sections are informative.


πŸ“ EXAMPLES πŸ“

None. β€” yeah bestie, they really just said "figure it out" 😭 iconic honestly


🧚 APPLICATION USAGE 🧚

Applications using this function may be subject to priority inversion, as discussed in the Base Definitions volume of POSIX.1‐2017, Section 3.291, Priority Inversion. Keep that in mind, it's not a drill. ⭐


πŸ‘‘ RATIONALE πŸ‘‘

If an implementation detects that the value specified by the barrier argument to pthread_barrier_wait() does not refer to an initialized barrier object, it is recommended that the function should fail and report an [EINVAL] error. So like, that's the recommendation β€” catching the uninitiated barrier and calling it out. πŸ’…


🌈 FUTURE DIRECTIONS 🌈

None. β€” nothing coming, it's perfect as is, no notes. πŸ’–


πŸ¦‹ SEE ALSO πŸ¦‹

  • pthread_barrier_destroy()
  • The Base Definitions volume of POSIX.1‐2017, Section 3.291, Priority Inversion
  • Section 4.12, Memory Synchronization
  • <pthread.h>

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!! πŸŽ€ courtesy of IEEE/The Open Group, 2017 β€” stan a standards body that gives us barriers to sync at. mwah πŸ’‹