From owner-freebsd-arch Mon Sep 11 19: 0:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3E23737B423 for ; Mon, 11 Sep 2000 19:00:35 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8C20To08937; Mon, 11 Sep 2000 19:00:29 -0700 (PDT) Date: Mon, 11 Sep 2000 19:00:29 -0700 From: Alfred Perlstein To: Greg Lehey Cc: arch@FreeBSD.ORG Subject: Re: Interruptable mutex aquires. Message-ID: <20000911190029.B12231@fw.wintelcom.net> References: <20000910193602.B12231@fw.wintelcom.net> <20000912111842.F88615@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000912111842.F88615@wantadilla.lemis.com>; from grog@lemis.com on Tue, Sep 12, 2000 at 11:18:42AM +0930 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Greg Lehey [000911 18:48] wrote: > On Sunday, 10 September 2000 at 19:36:02 -0700, Alfred Perlstein wrote: > > > > Some people have discussed making a new flag 'MTX_CATCH', personally > > that sounds terrible, I'm already not really thrilled with the > > 'do-all' functions that have been put into place as our primatives, > > as they are not very intuative, it's hard to tell at a glance > > exactly what is a spinlock and what is a task switching mutex, let's > > _please_ try to keep this readable and stick away from the flags. > > I suppose there's a case for simpler terminology, but have you looked > at the mutex code? There's a *lot* of code in there, and apart from > the duplication, maintenance would be terrible. I'd suggest the flag > approach, but there's nothing stopping a macro encapsulation with a > name like mtx_enter_interruptable. That could work. > > At the BSDi/FreeBSD SMP meeting I remeber asking Chuck why he > > implemented it this way, his respnonse was something along the lines > > of "it seemed like a good idea to have an object that one could spin > > or sleep on depending on the locatation or state of the object > > encapsulating the mutex, but in practice we've never used nor needed > > to use a mutex as a spinlock or a spinlock as a mutex" > > Ugh. Another use of the word "mutex". I thought we were using mutex > to cover both terms. > > Don't forget that BSD/OS 5 hasn't been released yet. Rather > amusingly, ours is available before theirs :-) But it's quite possible > that they will find a use for this kind of mutex. I find it annoying to have to wrap what should be a simple interruptable mutex with a very complex code, nothing that Jason presented looked easy to parse. Honestly though, since my initial request for this feature and subsequent workaround that _was_ needed (mtx_enter_intr was not an option actually) I haven't really come across anything that really needs it. > > [*] yes, today's C compilers actually support identifiers longer > > than 6 characters! if mtx_enter_interruptable is too offensive > > I could live with mtx_enter_intr(). > > This isn't a question of identifier length, it's a question of > style(9). As long as we have 8 character indentation and only 80 > characters text width, we're damned to using short identifiers. The Linux core kernel seems able to produce more readable code than ours constantly. In fact our in house coding practices strictly follow style 9 with the exception of almost always using {} for surrounding control blocks, we usually don't have any problems with descriptive identifiers. Then again we set our tab stops to 4 characters, as I do with any kernel code that I introduce. I think the golden rule is: If it takes you more than 5 minutes to think of a cute and 'descriptive' way to abbreviate something, then it's probably not descriptive at all. :) -- -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