Date: Sat, 24 Nov 2012 16:21:03 +0000 From: Attilio Rao <attilio@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org, Oleksandr Tymoshenko <gonzo@bluezbox.com> Subject: Re: [RFC] sema_wait_sig Message-ID: <CAJ-FndA_uWxp5pDgTCSFWN9LSY7TS%2Bzr8xN83fSEAhiQ3dQyzQ@mail.gmail.com> In-Reply-To: <50B0F306.6020906@mu.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndA_uWxp5pDgTCSFWN9LSY7TS%2Bzr8xN83fSEAhiQ3dQyzQ>