Skip site navigation (1)Skip section navigation (2)
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>