Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Sep 2000 08:27:55 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        mjacob@feral.com
Cc:        tlambert@primenet.com (Terry Lambert), brian@Awfulhak.org (Brian Somers), grog@wantadilla.lemis.com (Greg Lehey), cp@bsdi.com (Chuck Paterson), archie@whistle.com (Archie Cobbs), joerg@cs.waikato.ac.nz (Joerg Micheel), frank@exit.com (Frank Mayhar), jhb@pike.osd.bsdi.com (John Baldwin), markm@FreeBSD.ORG (Mark Murray), FreeBSD-arch@FreeBSD.ORG
Subject:   Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files
Message-ID:  <200009250827.BAA12659@usr02.primenet.com>
In-Reply-To: <Pine.GSO.4.21.0009242036250.506-100000@bird.feral.com> from "Matthew Jacob" at Sep 24, 2000 08:38:56 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> > This is easy: mark them non-reentrant.  You can either acquire a
> > mutex on descent into them and release it on exit/sleep, or (and
> > this is better), have a per-module mutex that's acquired on the
> > descent/wakeup and released on the ascent, if the flag is present.
> > This will let the modules be corrected on a per FS and per CAM
> > driver basis, while maintaining legacy compatability.  We do not
> > need another ethnic clensing of the drivers, such as what we went
> > through when CAM went in, or when the X.25 and ISODE stuff was
> > murdered.
> 
> Hmm, but I sure don't want the pain of the 'unsafe_driver' mutex that Sun went
> thru. Still- your point has a lot of maerit.

One of the best things that UnixWare had going for it was the
ability to continue using legacy drivers, file systems, and
streams stacks, while those components that were reentrant
were capable of giving better performance.

UnixWare on a UP box was capable of 30% better performance,
even after all of the SMP overhead, simply because the
system was mostly reentrant (this with the terrible hit
that the network stack took trying to use ODI drivers).

I think that no matter how you slice it, it has to be possible
for something to be done right, and to tell the difference
between those things that are and aren't reentrant, easily
and unequivocally.

With the suggested mutex recursion (please -- use a counting
semaphore, not a mutex, if you are going to permit recursion!),
the only way would be to instrument the mutex acquisition
macro to whine to the console any time the count increments
after it reaches a value of 1.

If you are willing to whine about recursion, then I suppose
that having recursion would not be that bad; but turn off
the whining, and there's little incentive to fix it, since
to many people's minds, it won't be broken.  8-(.


					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-arch" in the body of the message




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