From owner-freebsd-arch Mon Sep 11 20: 8:16 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 0DD0337B422 for ; Mon, 11 Sep 2000 20:08:14 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA14349; Mon, 11 Sep 2000 23:07:56 -0400 (EDT) Date: Mon, 11 Sep 2000 23:07:56 -0400 (EDT) From: Daniel Eischen To: Alfred Perlstein Cc: Jason Evans , Greg Lehey , arch@FreeBSD.ORG Subject: Re: Long-term mutex ownership (was Re: Interruptable mutex aquires.) In-Reply-To: <20000911192610.D12231@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 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(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message