On Illumos and Solaris I want to make this optional and off by default. The Illumos man page for pthread_cond_broadcast says The pthread_cond_signal() or pthread_cond_broadcast() 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 is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast(). Here is the Illumos implementation of pthread_barrier_wait: int pthread_barrier_wait(pthread_barrier_t *barrier) { mutex_t *mp = (mutex_t *)&barrier->__pthread_barrier_lock; cond_t *cvp = (cond_t *)&barrier->__pthread_barrier_cond; uint64_t cycle; int cancel_state; (void) mutex_lock(mp); if (--barrier->__pthread_barrier_current == 0) { barrier->__pthread_barrier_cycle++; barrier->__pthread_barrier_current = barrier->__pthread_barrier_count; (void) mutex_unlock(mp); (void) cond_broadcast(cvp); return (PTHREAD_BARRIER_SERIAL_THREAD); } (void) pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cancel_state); cycle = barrier->__pthread_barrier_cycle; do { (void) cond_wait(cvp, mp); } while (cycle == barrier->__pthread_barrier_cycle); (void) pthread_setcancelstate(cancel_state, NULL); (void) mutex_unlock(mp); return (0); } The key thing there is (void) mutex_unlock(mp); (void) cond_broadcast(cvp); That means that there is a "dubious associated lock" error every time that pthread_barrier_wait fires due to the barrier count reaching zero.
https://bugs.kde.org/show_bug.cgi?id=392331 ^^^ probably the reason that I'll generalise this for all platforms.
commit 954eadb149d5165700fc3ed6d47e435d3c381531 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Fri Apr 18 13:35:45 2025 +0200 Bug 502871 - Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread" optional