Date: Sun, 25 Jan 2009 22:53:44 -0800 From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: arch@freebsd.org, Kip Macy <kmacy@freebsd.org> Subject: Re: need for another mutex type/flag? Message-ID: <497D5DF8.8000706@elischer.org> In-Reply-To: <20090125092838.GC87077@elvis.mu.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <20090125092838.GC87077@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Jeff Roberson <jroberson@jroberson.net> [090125 01:21] 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. >> >> What is the case you have where you can not acquire non leaf mutexes? > > Jeff, I think that Julian really wants to prevent a sleep inside > his context. Right now, I think we only check for mutexes held > before a sleep that arne't sleepable. It might make sense to allow > one to just mark a thread non-sleepable even though no mutex is > held. > > Julian, is that right? basically, though I don't know the details of implementation.. I just know that mutexes per se aren't bad for netgraph but that node authors need some guidance on how to use them and some way to prove to them when they do the wrong thing. > >> Thanks, >> Jeff >> >>>> -Kip >>>> >>>> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org> >>>> wrote: >>>>> Currently we have: >>>>> spin locks.. >>>>> you really don't want to hold these for >>>>> any time at all, and this is enforced to some extent in the waiter. >>>>> >>>>> regular mutexes.. >>>>> You can hold these for as long as you want but teh shorter >>>>> the better and you can't sleep when holding them. The >>>>> "shortness" of the time of holding the mutex is not enforced. >>>>> >>>>> "Sleeps" (including sx-locks and friends) >>>>> You may hold these or be descheduled for really long periods of time. >>>>> >>>>> >>>>> Now it occurs to me that there is a subclass of regular mutexes, >>>>> usage, which is where you want to use a mutex to guard some small >>>>> but critical structure, and that you know that access to that structure >>>>> will >>>>> be quick, and that you can guarantee that you will >>>>> not acquire any other locks (which could introduce unknown delay) >>>>> while hoding the lock. >>>>> >>>>> One way of thinking about this is that this lock would always be >>>>> a leaf node on the tree of lock orders. >>>>> I would like to be able to add a flag to a mutex >>>>> that tags it as a 'leaf' mutex. As a result it would be illegal >>>>> to take any other mutex while holding a leaf mutex. Somewhat >>>>> similar to the way that it is illegal to take aregular >>>>> mutex while holding a spin mutex.. >>>>> >>>>> >>>>> In netgraph I have a stipulation that is hard to specify which >>>>> is that you MAY take a mutex in a netgraph node if you can guarantee >>>>> that the mutex WILL be satisfied very quickly, but it'd >>>>> be nice to be able to specify "you may only take 'leaf' mutexes within an >>>>> netgraph node". >>>>> >>>>> >>>>> thoughts? (especially from jhb and other locking types). >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-arch@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>>>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497D5DF8.8000706>