From owner-freebsd-smp Mon Apr 28 10:52:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27588 for smp-outgoing; Mon, 28 Apr 1997 10:52:19 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27581 for ; Mon, 28 Apr 1997 10:52:15 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02220; Mon, 28 Apr 1997 10:50:21 -0700 From: Terry Lambert Message-Id: <199704281750.KAA02220@phaeton.artisoft.com> Subject: Re: SMP To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Date: Mon, 28 Apr 1997 10:50:21 -0700 (MST) Cc: black@zen.cypher.net, chuckr@mat.net, FreeBSD-SMP@FreeBSD.org In-Reply-To: <199704280416.XAA12986@nyx.pr.mcs.net> from "Chris Csanady" at Apr 27, 97 11:16:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >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.