Re: pthread_cond_signal/broadcast: necessary to hold mutex?

On Mon, 23 Mar 2026 23:23:45 +0100
Thomas Klausner <[email protected]> wrote:

> On Mon, Mar 23, 2026 at 10:39:55PM +0100, Tobias Nygren wrote:
> > On Mon, 23 Mar 2026 21:50:41 +0100
> > Thomas Klausner <[email protected]> wrote:
> > 
> > > - Time for a bug report?
> > > - Any ideas where this requirement comes from?
> > 
> > The hardcopy of "DEC OSF/1 Guide to DECthreads" DEC p/n AA-Q2DPB-TK
> > printed in 1994 which I happen to still have in my possession states on
> > page 56 for pthread_cond_wait:
> > 
> > ```
> > Call this routine after you have locked the mutex specified in /mutex/. The results of this routine are unpredictable without first locking the mutex.
> > ```
> > 
> > This predates the first publication of pthreads in IEEE 1003.1c-1995.
> > The wording strongly suggest that you should lock the mutex but doesn't
> > explicitly forbid not doing so. I guess POSIX copied those semantics but
> > made them more clear, as standards people do.
> > 
> > I think it would be OK to
> > s/must be held/must be held for defined behaviour/
> > in our manpage.
> 
> Perhaps I gave too much context.
> 
> I'm not talking about the *wait* part, I agree that the mutex needs to
> be held there.
> 
> I was only talking about *signal and *broadcast.

I see. The historical printed documentation explictly states for
pthread_cond_signal:

```
You can call this routine regardless if the associated mutex is locked.
```

And for pthread_cond_broadcast:

```
You can call this routine whether the associated mutex is locked or not.
```