From owner-freebsd-arch Tue Sep 12 1:28:11 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 C881237B43E for ; Tue, 12 Sep 2000 01:28:08 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8C8S1J17679; Tue, 12 Sep 2000 01:28:01 -0700 (PDT) Date: Tue, 12 Sep 2000 01:28:01 -0700 From: Alfred Perlstein To: Daniel Eischen Cc: Jason Evans , Greg Lehey , arch@FreeBSD.ORG Subject: Re: Long-term mutex ownership (was Re: Interruptable mutex aquires.) Message-ID: <20000912012801.G12231@fw.wintelcom.net> References: <20000911192610.D12231@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from eischen@vigrid.com on Mon, Sep 11, 2000 at 11:07:56PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Daniel Eischen [000911 20:08] wrote: > On Mon, 11 Sep 2000, Alfred Perlstein wrote: > > * Jason Evans [000911 19:24] wrote: > > > On Tue, Sep 12, 2000 at 11:41:54AM +0930, Greg Lehey wrote: > > > > I think we need to come to some kind of consensus about how we are > > > > going to structure locking before we go into this much detail. At the > > > > moment we don't even agree whether we can hold on to (blocking) > > > > mutexes for long periods of time. > > > > > > I don't recall the original argument against holding mutexes for long > > > periods. From an abstract point of view, there's nothing wrong with such > > > practice, and in fact it makes sense for many problems. Is there an issue > > > with our implementation? If so, can someone please explain it? > > > > You are currently unable to abort if a signal comes in. :) > > > > Conditional variables add overhead and complexity where it's > > not needed. > > On the contrary. Our current mutex scheme with all the flags is > not as simple and as easy to understand as other OS kernel mutexes > I've dealt with. Having flags to mtx_enter() makes it more error > prone and I'd rather just use the mutex as it was mtx_init()'d. > I don't even want recursive mutexes and think that simple mutexes > with separate count fields should be used (I would probably lose > this argument though). > > Condition variables are used when you plan on waiting for something, > like I/O completion. You can wake one or all threads waiting on > condition variables. This is not typical of mutexes. Our current > splXXX()/tsleep()/splx() scheme corresponds very nicely with > mtx_enter()/cv_wait()/mtx_exit(). I don't recommend obfuscating > mutexes even more by creating yet another variant to be used > in place of tsleep() or cv_wait(). It's amazing what a rum and coke can do for one's concentration, you guys are right and I wish someone had looked at the code I was trying to work with, shook me and said "Alfred, you dumbass!" but then again I only have myself to blame here. :) The socketbuffer stuff is a prime example of what needs conditional variables and I didn't realize I was rolling my own using flags and msleep. *sigh* :) I am going to grep the Linux kernel and see if they have any examples of where an interruptable mutex is needed, but for now I don't need it and conditional variables would seem to be a nice thing. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message