Date: Thu, 24 Jun 1999 16:59:07 -0400 From: "David E. Cross" <crossd@cs.rpi.edu> To: Alfred Perlstein <bright@rush.net> Cc: Karl Denninger <karl@Denninger.Net>, "Brian F. Feldman" <green@unixhelp.org>, Doug <Doug@gorean.org>, Mark Newton <newton@internode.com.au>, drosih@rpi.edu, grog@lemis.com, mike@smith.net.au, hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: Microsoft performance (was: ...) Message-ID: <199906242059.QAA68044@cs.rpi.edu> In-Reply-To: Message from Alfred Perlstein <bright@rush.net> of "Thu, 24 Jun 1999 15:22:36 CDT." <Pine.BSF.3.96.990624150634.14320D-100000@cygnus.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD 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?199906242059.QAA68044>