Date: Mon, 28 Apr 1997 12:30:28 -0600 From: Steve Passe <smp@csn.net> To: Terry Lambert <terry@lambert.org> Cc: FreeBSD-SMP@FreeBSD.org Subject: Re: SMP Message-ID: <199704281830.MAA26677@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Mon, 28 Apr 1997 10:50:21 PDT." <199704281750.KAA02220@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > So fake it. Define per subsystem locks that, in implementation, access > the global lock. > > The only time you have to worry about reentrancy is when you are accessing > a common object. > > The first stage of the push-down is to access the global lock at multiple > choke-points in each subsystem rather than at the single choke-point in > the trap code. Things like "getpid" which can't sleep pending a resource > don't need locks at all, at that point. The getppid is a bit more of a > problem, if one thread of a process is disassociating (becoing a child of > init) at the time another thread is calling; so you need to be careful > with your assumptions to not screw future multithreading. it is definately time to start designing this area for real. we will undoubtedly have many lively discussions about lock models and strategies, but one thing that should preceed this is a "survey" of the current kernel to identify the critical regions. Once (and IMHO only once) we have a complete "map" that we can stand back and look at, will we be in a position to start design. If we just jump in and say "separate locks for a, b, & c" we are doomed to waste valuable time debuging dead-locks and crashes. such a strategy might work for the first 50% of improvement, but that last 50%... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704281830.MAA26677>