Date: Sun, 25 Jan 2009 01:27:12 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org, Kip Macy <kmacy@freebsd.org> Subject: Re: need for another mutex type/flag? Message-ID: <20090125092712.GB87077@elvis.mu.org> In-Reply-To: <497C2E82.6010600@elischer.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <497C2E82.6010600@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Julian Elischer <julian@elischer.org> [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 sleeps. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090125092712.GB87077>