Re: pthread_cond_signal/broadcast: necessary to hold mutex?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 24 Mar 2026 17:07:33 +0300
    From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
    Message-ID:  <acKapdPD1DKndfbM%snips.stderr.spb.ru@localhost>

  | My knowledge of synchronization primitives is cargo-cultish at best,
  | and so I tend to defer to Solaris manuals.

Me too - except I no longer have any Solaris manuals... (haven't been
near a Solaris system in decades, not a Digital Unix system either).

  | "can" above is a vague word.  It probably tells you that the function
  | itself doesn't touch the mutex and thus the function call itself does
  | not depend on whether the mutex is locked or not.

From what I see in the code, the latter, yes, the former, no, not really,
as the intent is to wakeup threads waiting on the mutex, then naturally,
it is going to be "touched".

I see nothing in our code that contradicts the posix spec, and certainly
see nothing which would require the mutex be held by the caller of
the pthread_cond_{signal,broadcast} functions.   Rather the code tests
whether the current thread does own the mutex, and if so, arranges the
wakeup to happen only after the current thread releases it.   Otherwise
it just happens as part of this call.

Whether or not the resulting sheduling is "predictable" or not is beyond
my comprehension, but predictable or not, it should be correct.


  | As far as I understand, the above caveat talks about the typical
  | waiting code that does:

There's no question, as I understand it, but that a thread performing
one of the cond_wait functions (there are several) must hold the mutex
while doing so, the example you gave looks aimed more at that than
anything releasing the mutex.

wiz, unless someone who knows more about this that I do (which means
just about anyone at all) contradicts this, I think you can safely
update the man pages to be like the posix spec says.

kre