Date: Thu, 24 Jun 1999 19:57:17 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: Karl Denninger <karl@Denninger.Net>, hackers@FreeBSD.ORG, "Brian F. Feldman" <green@unixhelp.org> Subject: Re: Microsoft performance (was: ...) Message-ID: <Pine.BSF.3.96.990624194114.14320E-100000@cygnus.rush.net> In-Reply-To: <199906242059.QAA68044@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Jun 1999, David E. Cross wrote:
> > A simple start would be to explicitly put a macro or call in each
> > syscall to push down the lock. That way people can move that
> > macro farther and farther down in the syscall code path, hopefully
> > removing it entirely in some cases. I think having the call at
> > the beginning of each syscall would motivate people into doing that
> > sort of work.
> >
> > "Hey, y'know getppid() is safe, i'll just take the lock out."
> > "this function xxx() is safe until this point I can process a lot
> > before actually needing this lock..."
> > "y'know I just have a structure that's not accessable to any other calls
> > that i'm going to fill in, i'll just lift the lock right here"
> > "if I just do this something here, I really am re-entrant and safe.."
> >
> > Providing a simple api for spinlocks and mutexes would be very nice.
> >
> > If some of the FreeBSD gods (core) said something along the lines
> > of we'd like to see the process table have XXX method of access
> > and locking people will code it, the same way with the many other
> > subsystems.
> >
> > Things like pmap and UFS and INET will be a royal pain to get
> > SMP safe, however baby steps towards lifting the lock for
> > simpler subsystems will lead the way. FreeBSD has the
> > most intellegent people in the industry working together,
> > all that is needed is a starting point.
>
> I think mutex is the way to go. I am 100% for it, and I think now that this
> problem is getting a good deal of light we should start to do something about
> it.
>
> One of the problems with locks that doesn't seem to have been mentioned
> (although I am sure many have thought it) is deadlocks. You get A waiting
> for B and b with A. With mutexi (plural?) you would lock just the resource
> that you are curently working on, and you would be guaranteed to release it
> (if the programmers do it right, of course ;). The advantage is with Mutex
> is that you don't need to be as omnipotent to use it.
Exactly, there are complex problems to deal with with locking
certain structures even in the UP model (when to raise spl() and
such)
My point is that if someone with the experiance defined protocols
for locking each subsystem we definetly have enough people to implement
it eventually. If the stupbs for this were in place it would motivate
people to work on it.
-Alfred Perlstein - [bright@rush.net|bright@wintelcom.net]
systems administrator and programmer
Win Telecom - http://www.wintelcom.net/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990624194114.14320E-100000>