Date: Mon, 28 Apr 1997 10:50:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Cc: black@zen.cypher.net, chuckr@mat.net, FreeBSD-SMP@FreeBSD.org Subject: Re: SMP Message-ID: <199704281750.KAA02220@phaeton.artisoft.com> In-Reply-To: <199704280416.XAA12986@nyx.pr.mcs.net> from "Chris Csanady" at Apr 27, 97 11:16:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >i sit corrected. i expect they will eventually migrate to a fully > >threaded kernel. > > As will we I hope. I was hoping to work on pushing the locks down > into the syscalls earlier, but I ran into some trouble. I really > knew very little about assembly, and our locks really are not up > to it yet. :( > > Besides, the general concencus was that we didn't want to deal with > it now.. 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. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704281750.KAA02220>