Re: pthread_cond_signal/broadcast: necessary to hold mutex?

Reading POSIX, I am unclear on how calling pthread_cond_broadcast with
the mutex held works.

I get it that when wanting to broadcast/signal, one can likely acquire
the mutex, assuming the[ consumer thread is in pthread_cond_wait.  And
that the mutex is about seralizing wait/wakeup to avoid missed wakeups.
It's not necesssarily about protecting the workqueue., but I suppose it
could be.

A thread wanting to signal would acquire the mutex and call signal.
That is allowable, even encouraged by the man page.  What is the state
of the mutex when the call returns?  This is hard to understand.  The
text does say that there is "no effect" if there are no waiters, and
that, somewhat weakly, implies the mutex is still held on return.  That
in turn suggests that even if there are waiters, it is also held on
return - because having that be nondeterministic would be crazy.

Thus, I conclude that the right thing is

  pthread_mutex_lock()
  pthread_cond_signal()
  pthread_mutex_unlock()

and only on unlock will a worker thread that was waiting be able to lock
the mutex and return to its caller.

But I feel that I have made a bunch of not-really-solid assumptions that
are not clearly required by the text.

Unconfusion welcome, especially if it can point to the POSIX text in a
crisper way.