NetBSD Problem Report #60122

From wiz@netbsd.org  Tue Mar 24 10:27:52 2026
Return-Path: <wiz@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7EDDA1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 24 Mar 2026 10:27:52 +0000 (UTC)
Message-Id: <20260324102751.E860B8556F@mail.netbsd.org>
Date: Tue, 24 Mar 2026 10:27:51 +0000 (UTC)
From: wiz@NetBSD.org
Reply-To: wiz@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: pthread_cond_broadcast/signal man pages claim to need mutex held
X-Send-Pr-Version: 3.95
X-From4GNATS: "wiz@NetBSD.org via gnats" <gnats-admin@NetBSD.org>

>Number:         60122
>Category:       lib
>Synopsis:       pthread_cond_broadcast/signal man pages claim to need mutex held
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 24 10:30:00 +0000 2026
>Originator:     Thomas Klausner
>Release:        NetBSD 11.99.5
>Organization:

>Environment:
Architecture: x86_64
Machine: amd64
>Description:
The NetBSD man page for pthread_cond_broadcast/signal claims that you
need to hold the mutex when sending the signal:

(about pthread_cond_*wait)

     With both functions the waiting thread unblocks after another thread
     calls pthread_cond_signal() or pthread_cond_broadcast() with the same
     condition variable and by holding the same mutex that was associated with
     cond by either one of the blocking functions.

...

(about pthread_cond_broadcast/signal)
     The same mutex must be held while
     broadcasting or signaling on cond.

but later also:

     In this implementation, none of the functions enforce this
     requirement, but if the mutex is not held or independent mutexes
     are used the resulting behaviour is undefined.

On the other hand, POSIX says you don't need to hold the mutex when
signaling:

https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_cond_broadcast.html
    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_clockwait(),
    pthread_cond_timedwait(), or pthread_cond_wait() 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().

Holding the mutex wasn't even required in the POSIX '97 edition:
https://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_cond_signal.html

     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
     behaviour is required, then that mutex is locked by the thread
     calling pthread_cond_signal() or pthread_cond_broadcast().

>How-To-Repeat:
Read the man pages, compare them to POSIX.
>Fix:
Update the man pages to document that holding the mutex for
pthread_cond_broadcast and pthread_cond_signal is not necessary.

But before that, make sure that the claim is correct.

I volunteer for the man pages, but would like someone else
to check libpthread.

Home	PR Database Search