Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Sep 2000 23:07:56 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Jason Evans <jasone@canonware.com>, Greg Lehey <grog@lemis.com>, arch@FreeBSD.ORG
Subject:   Re: Long-term mutex ownership (was Re: Interruptable mutex aquires.)
Message-ID:  <Pine.SUN.3.91.1000911224108.11203A-100000@pcnet1.pcnet.com>
In-Reply-To: <20000911192610.D12231@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Sep 2000, Alfred Perlstein wrote:
> * Jason Evans <jasone@canonware.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000911224108.11203A-100000>