Date: Sat, 24 Nov 2012 15:21:12 +0000 From: Attilio Rao <attilio@freebsd.org> To: Oleksandr Tymoshenko <gonzo@bluezbox.com> Cc: arch@freebsd.org Subject: Re: [RFC] sema_wait_sig Message-ID: <CAJ-FndBuzkmsKzkmKaT%2BwDic5%2B%2B18dBgFO%2BdKcqPGvSp1d%2BGsg@mail.gmail.com> In-Reply-To: <CAJ-FndD-EoKt=exd12NQQcufvQ-CZ4PC2=a8qrA2r%2B-uLk9Cqw@mail.gmail.com> References: <E5FE70A7-D2D2-4021-950B-48FD84F11F08@bluezbox.com> <CAJ-FndD-EoKt=exd12NQQcufvQ-CZ4PC2=a8qrA2r%2B-uLk9Cqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- 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-FndBuzkmsKzkmKaT%2BwDic5%2B%2B18dBgFO%2BdKcqPGvSp1d%2BGsg>