need for another mutex type/flag?

[Daniel Eischen]

On Tue, 27 Jan 2009, Julian Elischer wrote:

> 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..

I thought all you wanted to mandate that the netgraph code
itself didn't nest any mutexes.  If it doesn't hold any of
its own mutexes while calling m_prepend(), etc, then is
that still a problem?

-- 
DE