Re: pthread_cond_signal/broadcast: necessary to hold mutex?

Jörg Sonnenberger <[email protected]> writes:

> On 3/25/26 12:03 AM, Greg Troxel wrote:
>> Thus, I conclude that the right thing is
>>    pthread_mutex_lock()
>>    pthread_cond_signal()
>>    pthread_mutex_unlock()
>
> Why do you signal a CV without actually changing some condition? If
> you see something like the above in real world code, it likely has a
> completely broken locking strategy.

I was leaving that out as separate; the queue could be separate.  But
sure, assume the queue is protected by the same mutex and before signal
there is "add this item to the queue".

(You didn't answet the question if the interpretation that the mutex
remains locked during and thus after the signal call is correct.)