Date: Fri, 13 Oct 2000 02:44:12 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: jasone@FreeBSD.ORG (Jason Evans), FreeBSD-smp@FreeBSD.ORG (FreeBSD SMP list) Subject: Re: New mutexes (was: cvs commit: src/sys/conf param.c src/sys/kern kern_lock.c src/sys/sys kernel.h lock.h src/sys/vm vm_map.h) Message-ID: <200010130244.TAA03795@usr05.primenet.com> In-Reply-To: <20001013103913.B2467@wantadilla.lemis.com> from "Greg Lehey" at Oct 13, 2000 10:39:14 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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?
The mines are anywhere more than 1 mutex is held, anywhere that
a mutex is held with a recursion count greater than 0, and
anywhere code that can sleep holds a mutex.
There are also "stealth" mines in any function that holds a
mutex over a break, goto, loop control structure, or
conditional statement that can return (e.g. any function that
is not single entry, single exit).
There are implied mines ("this side towards enemy" screwup
potential) everywhere there is data manipulation of anything but
stack data, where a mutex is _not_ held.
There are "bouncing betties" (mines which blow up later, killing
the rest of the squad, when the point man screws up) everywhere
an interrupt or trap handling function doesn't hold a mutex over
an implied mine. These have the benefit of leaving the point
man alive, so that when he's reassigned, he can kill the next
squad following him, too.
---
As to tracking them: use a mutex. 8-).
Acquire the mutex that allows you to add a mutex
Add the new mutex
Release the mutex adding mutex (Requires you to document your addition)
You might recognize this as multiple reader/single writer locks
on the source tree, with overall change comments, circa 1994, as
in:
Acquire:
co -l changemutex
Add new mutex:
cvs ci
Release/document:
ci -u changemutex
Back in 1992/1993, we had shell scripts that wrapped CVS and added
a "cvs lock" and "cvs unlock" (and "cvs unlock -f") "subcommands"
to support this (this was at Novell).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?200010130244.TAA03795>