Re: pthread_cond_signal/broadcast: necessary to hold mutex?

Thomas Klausner <[email protected]> writes:

> On Tue, Mar 24, 2026 at 08:31:29AM +0100, Greg Troxel wrote:
>> Thomas Klausner <[email protected]> writes:
>> 
>> > On Mon, Mar 23, 2026 at 05:19:18PM +0100, Greg Troxel wrote:
>> >> Also, our man page talks about "changing the mutex" associated with the
>> >> pthread_cond_t, but as I read POSIX there is no rule that you can't have
>> >> N threads waiting on the same condvar each with a different mutex.  The
>> >> mutex is just about the wait caller, holding it on entry and getting it
>> >> back later, with it released in between.
>> >> 
>> >> It would be interesting to see what the code does; this could just be a
>> >> doc issue.
>> >
>> > How I understand the code is that a mutex is saved in the cond
>> > structure, and there is only place for one - so I think the
>> > requirement is actually true in NetBSD.
>> 
>> That is a separate bug then, as I understand POSIX.
>
> I disagree.
>
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_cond_clockwait.html
>
>     When a thread waits on a condition variable, having specified a
>     particular mutex to the pthread_cond_clockwait(),
>     pthread_cond_timedwait(), or pthread_cond_wait() operation, a
>     dynamic binding is formed between that mutex and condition
>     variable that remains in effect as long as at least one thread is
>     blocked on the condition variable. During this time, the effect of
>     an attempt by any thread to wait on that condition variable using
>     a different mutex is undefined.
>
> Note the last sentence.

You are right -- I misread/misremembered.