Date: Mon, 11 Sep 2000 19:00:29 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Greg Lehey <grog@lemis.com> Cc: arch@FreeBSD.ORG Subject: Re: Interruptable mutex aquires. Message-ID: <20000911190029.B12231@fw.wintelcom.net> In-Reply-To: <20000912111842.F88615@wantadilla.lemis.com>; from grog@lemis.com on Tue, Sep 12, 2000 at 11:18:42AM %2B0930 References: <20000910193602.B12231@fw.wintelcom.net> <20000912111842.F88615@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Greg Lehey <grog@lemis.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000911190029.B12231>