Date: Tue, 26 Sep 2000 23:04:37 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Greg Lehey <grog@lemis.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Daniel Eischen <eischen@vigrid.com>, John Polstra <jdp@polstra.com>, arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <20000926230436.J9141@fw.wintelcom.net> In-Reply-To: <20000927143318.H7583@sydney.worldwide.lemis.com>; from grog@lemis.com on Wed, Sep 27, 2000 at 02:33:18PM %2B1100 References: <Pine.SUN.3.91.1000925055843.15658A-100000@pcnet1.pcnet.com> <200009252123.e8PLN5F84806@earth.backplane.com> <20000925143853.J9141@fw.wintelcom.net> <20000927143318.H7583@sydney.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Greg Lehey <grog@lemis.com> [000926 20:34] wrote: > On Monday, 25 September 2000 at 14:38:54 -0700, Alfred Perlstein wrote: > > > We should be coding and discussing existing problems with making the > > kernel MPsafe instead of what me *might* come across along the road. > > I certainly think that at the moment we should be thinking about > structure rather than details. I think we've been doing that for two years already and it hasn't bought us squat. > > Whatever we bump into we can always beat to a pulp using lockmgr. :) > > Well, can anybody put up good arguments for keeping lockmgr in the > long term? I'm not saying there aren't any, but I haven't analysed it > enough yet. lockmgr offers many styles of locking over a common lock interface, it allows one to upgrade and downgrade a lock's read/write status without loosing them and i'm pretty sure it also allows for recursion, although that may be broken ATM. > > And honestly, I don't like the idea of recursive mutexes, I'd rather > > have a super function that locks a pgrp like > > pg_signal_locked/_unlocked which expects the locks to be held rather > > than a recursive lock. > > I think that eliminating recursion requires you to understand the > system much better, which brings both advantages and disadvantages. Greg, after looking over this stuff for what seems like centuries I can honestly say that with the exception of VFS and VM the system is pretty straightforward (well proc/pgrp isn't much fun, but it's not deadly). If anyone has any doubts about what type of locking they'll need, then they need to look at the BSD/os code, because they've already done it! What we need to be have is discussions about the way people plan to push the locks in deeper, if it involves recursive mutexes, conditional variables or green moon cheese, I really don't care so as long as it's backed up by a real application for the primatives that they want in our codebase. Right now I can't even do getpid() properly because we don't have read/write-barriers. So far I like what I see in BSD/os, are we going to continue taking advantage of the reference implementation we've been given or wander off into nothingness? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000926230436.J9141>