From owner-freebsd-arch Sun Sep 10 20:36:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5719B37B423 for ; Sun, 10 Sep 2000 20:36:30 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA14835; Sun, 10 Sep 2000 23:36:12 -0400 (EDT) Date: Sun, 10 Sep 2000 23:36:11 -0400 (EDT) From: Daniel Eischen To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: Interruptable mutex aquires. In-Reply-To: <20000910193602.B12231@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 10 Sep 2000, Alfred Perlstein wrote: > > There's a lot of code in the kernel that does this: > > while(lock != mine) { > error = tsleep(&lock, PRIBIO, "foo", PCATCH); > if (error) > return(error); > } > lock = mine; > > Ok, well the equivelant way to do this with mutexes would be > to add a new function 'mtx_enter_interruptable()' [*] > that attempts to aquire a mutex but if interrupted returns > an error suitable for aborting the operation. I don't think we want to equate tsleep() with mtx_enter(). I'd rather see us use msleep_sig() until condition variables are added and then use cv_wait_sig() (or something like that). Mutexes should be taken for very short times, and we shouldn't worry about them being interrupted unless they surround a tsleep()/msleep(). > > Nice, easy, simple and fits well as a replacement tool for > the current while(lock != mine) mechnism. > > 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 sort of agree but can see why the flags were used instead of relying on mtx_init() to set the type of mutex. I wonder if we are too concerned about trying to squeeze an extra .5% performance for recursive mutexes, than with trying to create a simple and understandable interface. > > I also think that we don't really need the overhead of a > return value if at all possible. > > 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" > > [*] 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(). I prefer *_sig() -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message