need for another mutex type/flag?

[Julian Elischer]

Robert Watson wrote:
> On Sun, 25 Jan 2009, Julian Elischer wrote:
> 
>> Even purely documentary would be good but given the option, I'd like 
>> it to scream when Witness is enabled and you try get another mutex....
>>
>> there are certain contexts (e.g. in most netgraph nodes) where we 
>> really want the authors to only take such locks and taking more 
>> unpredictable mutexes plays havoc with netgraph response times as a 
>> system as a whole, since if one node blocks, teh thread doesn't get to 
>> go off and service other nodes.
> 
> I thought lots of Netgraph nodes liked to do things like call m_pullup() 
> and m_prepend()?  Disallowing acquiring mutexes will prevent them from 
> doing that.

I think I mentioned that in another mail.
The problem I see is that some module writers are tempted to
just use a mutex in their node without thinking about what the
result will be.  My understanding is that the mbuf allocation
code has been tuned to within an inch of its life to try
keep it's waits to a minimum.  I am worried about it,
but I am more worried about a netgraph node waiting on something
that is depending on some piece of hardware such as what I think
HPS had in his suggested patch for the bluetooth code..

> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"