Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pthread_cond_signal/broadcast: necessary to hold mutex?



On Tue, Mar 24, 2026 at 08:31:29AM +0100, Greg Troxel wrote:
> Thomas Klausner <wiz%netbsd.org@localhost> 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.
 Thomas


Home | Main Index | Thread Index | Old Index