Date: Sat, 24 Nov 2012 08:17:10 -0800 From: Alfred Perlstein <bright@mu.org> To: attilio@FreeBSD.org Cc: arch@freebsd.org, Oleksandr Tymoshenko <gonzo@bluezbox.com> Subject: Re: [RFC] sema_wait_sig Message-ID: <50B0F306.6020906@mu.org> In-Reply-To: <CAJ-FndBuzkmsKzkmKaT%2BwDic5%2B%2B18dBgFO%2BdKcqPGvSp1d%2BGsg@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. According to this post I shouldn't touch anything that has to do with any SMP stuff until you complete your upcoming work because it will all be turned upside down. This is not what people should think about FreeBSD, it will drive developers away. Heck, I'm scared now to even write anything. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B0F306.6020906>