Date: Sat, 24 Nov 2012 10:06:40 -0800 From: Alfred Perlstein <bright@mu.org> To: Daniel Eischen <deischen@freebsd.org> Cc: attilio@freebsd.org, arch@freebsd.org, Oleksandr Tymoshenko <gonzo@bluezbox.com> Subject: Re: [RFC] sema_wait_sig Message-ID: <50B10CB0.6040406@mu.org> In-Reply-To: <Pine.GSO.4.64.1211241158550.24054@sea.ntplx.net> References: <E5FE70A7-D2D2-4021-950B-48FD84F11F08@bluezbox.com> <CAJ-FndD-EoKt=exd12NQQcufvQ-CZ4PC2=a8qrA2r%2B-uLk9Cqw@mail.gmail.com> <CAJ-FndBuzkmsKzkmKaT%2BwDic5%2B%2B18dBgFO%2BdKcqPGvSp1d%2BGsg@mail.gmail.com> <50B0F306.6020906@mu.org> <Pine.GSO.4.64.1211241158550.24054@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/24/12 9:10 AM, Daniel Eischen wrote: > On Sat, 24 Nov 2012, Alfred Perlstein wrote: > >> On 11/24/12 7:21 AM, Attilio Rao wrote: >>> On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao <attilio@freebsd.org> >>> wrote: >>>> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >>>> <gonzo@bluezbox.com> wrote: >>>>> Hello, >>>>> >>>>> Is there any particular reason FreeBSD does not have sema_wait_sig >>>>> function? It seems to be easily implementable using cv_wait_sig >>>>> function. >>>> The sema(9) primitive is considered obsolete/dying. >>>> You should really use mtx + condvar (so just go using cv_wait_sig() >>>> directly). >>>> >>>> I had a patch to remove it all from the kernel few years ago but I >>>> never got to commit it. >>>> It would be good if we can remove this primitive off before 10.0. >>> Before to start receiving bikeshead e-mails by "savers of the nation", >>> let me explain this a bit. This cames directly from the necessity to >>> shrunk the number of locking primitives we offer, in particular when >>> such primitives have very naive/non-standard interface, meant as >>> dangerous and not intuitive KPI. >>> The biggest 2 beasts to chase are then sema(9) and lockmgr(9). >>> >>> The former should be replaced by a smart use of mtx + flags/counters + >>> sleep(9)/condvar(9). I see some of the usage are the ones that want >>> the first locker to sleep (counter as 0 at init time), for example. >>> >>> The latter should be replaced by sx(9) interface, but that's very >>> tricky. lockmgr have a lot of strange patterns which require a fair >>> bit of understanding and work to be controlled (LK_DRAIN, >>> LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx >>> might grow up some further operations to cope with it (namely the >>> interlock and maybe disowning) but that's really minor turbolence as >>> removing redundant lockmgr would be a big win for us. Right now it is >>> just a burden and more code to maintain for a very little gain. >>> >>> As a last item, we may also look at splitting the sleep-mtx and >>> spin-mtx interface and replace all the occurence of the former with >>> rwlocks, of course always held in write mode. This way the mtx(9) will >>> only serve spinlocks and their implementation will be very self >>> contained. >>> >>> Thanks, >>> Attilio >>> >>> >> >> People have been trying to "kill lockmgr" for 5+ years now. >> >> In the meanwhile discouraging people from using things that make >> their lives easier in porting drivers is probably wrong. > > Have you seen how many places sema(9) is used in the kernel? Not > many, and it seems trival to replace them with mtx and cv pairs. > The man page even says not to use sema(9) where mutexes and condition > variables will suffice. > > I don't think getting rid of sleep mutexes should be done. The > mtx interface should be similar to the userland interface, so > that it is consistent for developers. > I know, it's trivial to replace lots of things with their constituent parts, until it's "all the things" and then you're spending all your time re-writing semaphores and mutexes and doing busy work instead of getting code done. But hey, if it bothers you so much that someone can easily port over Linux drivers, or that a Linux kernel dev can come to FreeBSD and easily get up to speed... then pull the rug out from under them. I guess. :) It doesn't make sense to me, but I don't really get the make-FreeBSD-hard-to-use-and-code-for group-think. Maybe eventually. :) -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B10CB0.6040406>