need for another mutex type/flag?

Alfred Perlstein alfred at
Sun Jan 25 01:42:28 PST 2009

* Julian Elischer <julian at> [090125 01:19] wrote:
> 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..

You could probably easily add this to witness_warn, basically
check a count in the thread that's recursive for not allowing

Currently, whenever a proceess would sleep, witness checks the
list of locks that the thread holds for locks that shouldn't
be slept on.

You could pretty easily add a check here too.

- Alfred Perlstein

More information about the freebsd-arch mailing list