Date: Sat, 24 Nov 2012 10:02:55 -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: <50B10BCF.3080407@mu.org> In-Reply-To: <CAJ-FndA_uWxp5pDgTCSFWN9LSY7TS%2Bzr8xN83fSEAhiQ3dQyzQ@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> <50B0F306.6020906@mu.org> <CAJ-FndA_uWxp5pDgTCSFWN9LSY7TS%2Bzr8xN83fSEAhiQ3dQyzQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/24/12 8:21 AM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 4:17 PM, Alfred Perlstein <bright@mu.org> 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. >> >> 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. > I don't have any plan to do it right now and if you want to follow > this you are welcome. > If you do want to do something else (like adding sema_wait_sig()) I'm > opposed to it and I'm giving you my opinion on why. > > You can do what you want then, but at least I'm free to say publically > what I think should be done to have correct code, or should I just let > people which have 0 history of contributing to SMP just turn upside > down all the last 15 years of work? > > Attilio > > Attilio, Please grep smp in http://people.freebsd.org/~alfred/alfred.logs.txt. It's not a lot, but it was when we first started going SMP and I worked very hard on this. Select locking, Filedesc locking, struct file... :) I guess this is a nice welcome back to the project. :) -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B10BCF.3080407>