need for another mutex type/flag?

Julian Elischer julian at elischer.org
Sun Jan 25 01:18:55 PST 2009


Jeff Roberson wrote:
> On Sun, 25 Jan 2009, Julian Elischer wrote:
> 
>> Kip Macy wrote:
>>> The adaptive spinning of regular mutexes already satisfies your need
>>> for "short" hold. You might wish to add a thread flag used when
>>> INVARIANTS is enabled that is set when a leaf mutex is acquired and
>>> checked on all mutex acquisitions.
>>
>> ummm that was what I was asking for.. an official designation of a 
>> 'leaf' mutex...
> 
> It'd be much easier to add the flag as a mtx_init() flag and have 
> witness check it.  It'd only take 15 minutes to do properly.

more or less what I was suggesting.

> 
> What is the case you have where you can not acquire non leaf mutexes?
> 
An example is netgraph. In netgraph you have one (or a small number) 
thread which is processing on behalf of a number of nodes which may be
doing work on behalf of completely different entities.
If such a worker thread blocks then other work becomes starved..

A similar example might be made for geom I expect. If a worker thread 
blocks other work can be starved.

Now you still in these modules need some way to synchronize
between threads to protect local resources etc. So you still
want to be able to use mutexes for this but you wnat to be able to
tell the module author "yes you can use mutexes but you can't
do so in a way that introduces any threat of undetirminsitic blocking".

i.e. once you have mutex in your node, to do something, do it quickly
and drop teh mutex, and do NOT go acquiring something that
might sleep on us.

I'm already worried about people getting mbufs etc in netgraph,
and it may turn out that we are already hitting this without
knowing it..




More information about the freebsd-arch mailing list