Re: Patch to "Lock struct pargs"

On Wed, 27 Mar 2002, Julian Elischer wrote:

> My first thought was "shouldn't the args be covered by th eproc lock"
> and then I noticed the ref-count.. obviously shared between processes.
> Then I thought "well why not an sx lock? I presume most processes access
> these read-only. 
> 
> THEN I thought.. hey hang on.. processes access their args from user
> space.. what are we storing here? so the comments in exec() etc seem to
> suggest that these are not the actual args that are given to the
> process, but instead some small subset used for (maybe) debugging..  if
> this is so then once again it's really only read-only when used.. any
> exec with a NEW set of args will create a new one.  so this is similar
> to the ucreds.. 
> 
> The only item we are protecting is the reference count.  Everything else
> should be read-only. You should only need to lock this when you are
> changing the reference count.  Once again an smp safe reference counting
> scheme would save this locking stuff.... 
> 
> John, can you resurect your ref-counting code so we can look at it
> again?  I think we could use it inteh ucred case too. 

One of the things they've done in IRIX in moving to extremely fine-grained
SMP is move from a copy-on-write notion for a number of shared structures
to simply using copies.  In some situations, they've moved into entirely
copies, in others, they've optimized some specific cases.  I don't think
pargs is an example of this due to its size, but it's something worth
keeping in mind.  The ucred model is actually quite a strong one, assuming
that the number of modifications is few (which is especially the case for
ucred where most references are *never* modified: structs file, socket,
etc).  Doesn't pargs already work this way?  I.e., if p1 modifies pargs,
it doesn't affect p2?  (I'm a bit source code unaware this morning since
my wife is in hospital and I'm pretty much there all day).

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[e-mail]      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-smp" in the body of the message