Question about cv_signal(9) (never mind)

[John Polstra]

On 14-Jun-2004 John Baldwin wrote:
> On Saturday 12 June 2004 08:12 pm, John Polstra wrote:
>> On 12-Jun-2004 John Polstra wrote:
>> > [Why does a caller to cv_signal(9) have to hold the associated mutex?]
>>
>> Never mind.  I understand now.  It allows the implementation to
>> avoid doing any locking internally.  That seems perfectly
>> reasonable, and I withdraw my question.
> 
> To be honest, it's also largely there to try to keep people from writing code 
> that can lose wakeups.  The count optimization came later.  If the 
> optimization of dropping the lock is more important and we think that people 
> really won't make the mistake of not using locks when they should to avoid 
> the lost wakeups then we could drop the count optimization and allow 
> cv_signal() to not require the lock perhaps.

It seems to me that some sort of mutual exclusion is needed when
manipulating the cv structure and the associated sleep queue.  If
the user doesn't provide it then the implementation will have to
provide it internally.  So unless there is a cheaper kind of mutual
exclusion that can be used inside the implementation, your current
solution seems the best to me.

I had never thought through the need for some kind of mutual
exclusion, and the papers that describe the optimization I mentioned
simply ignore it and its performance implications.

John