Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Oct 2000 19:04:43 -0700
From:      Jason Evans <jasone@canonware.com>
To:        Greg Lehey <grog@lemis.com>
Cc:        FreeBSD SMP list <FreeBSD-smp@FreeBSD.org>
Subject:   Re: New mutexes
Message-ID:  <20001012190443.G11949@canonware.com>
In-Reply-To: <20001013103913.B2467@wantadilla.lemis.com>; from grog@lemis.com on Fri, Oct 13, 2000 at 10:39:14AM %2B0930
References:  <200010122237.PAA12428@freefall.freebsd.org> <20001013103913.B2467@wantadilla.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 13, 2000 at 10:39:14AM +0930, Greg Lehey wrote:
> On Thursday, 12 October 2000 at 15:37:29 -0700, Jason Evans wrote:
> >   For lockmgr mutex protection, use an array of mutexes that are allocated
> >   and initialized during boot.  This avoids bloating sizeof(struct lock).
> >   As a side effect, it is no longer necessary to enforce the assumtion that
> >   lockinit()/lockdestroy() calls are paired, so the LK_VALID flag has been
> >   removed.
> 
> I'm just doing the slides for the Con, and going through the sources I
> note that we have sprouted a plethora of mutexes over the last month.
> How are we keeping track of them?  How does somebody who wants to add
> a new mutex know where the mines are?

I'm not sure I understand what you're getting at, if you're using my commit
as an example.  The lockmgr mutexes are leaf locks, so for most intents and
purposes (i.e. unless someone is mucking with the lockmgr code itself), no
one needs to know that they exist.  What issues are you implying exist for
someone who wants to add a new mutex to the system, that can be solved by
cataloging all mutex instances?

I would agree if you were to state that care must be taken to follow
certain rules in order to avoid bad mutex interactions, but I'm missing why
you think a mutex catalogue is a necessary thing.

On a related note (and perhaps the real answer you're looking for), John
Baldwin and Chuck Paterson came up with an initial set of rules for kernel
synchronization (subject to change), which is available at:

http://people.freebsd.org/~jasone/smp/smp_synch_rules.html

While I'm at it, here's a reminder that the SMP project status is being
tracked at:

http://people.freebsd.org/~jasone/smp/

Jason


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001012190443.G11949>