Date: Mon, 20 Nov 2000 12:56:15 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Jake Burkholder <jburkhol@home.com> Cc: smp@FreeBSD.org Subject: Re: patch: allproc_lock Message-ID: <XFMail.001120125615.jhb@FreeBSD.org> In-Reply-To: <20001120203045.3DAB8BA7A@io.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Nov-00 Jake Burkholder wrote: >> >> On 20-Nov-00 Jake Burkholder wrote: >> >> >> >> Attached is a patch that adds allproc_lock. This is a lockmgr >> >> lock which protectes the following: >> >> >> >> allproc >> >> zombproc >> >> pidhashtbl >> >> proc.p_list >> >> proc.p_hash >> >> nextpid >> >> >> >> Please review it. >> > >> > Sorry, too quick with the send...<blush> >> >> Well, I kind of don't like having allproc_lock/unlock functions. >> I would prefer explicit lockmgr() calls with on an allproc_lock >> variable. Also, we might consider having a very early > > Sure, how come? I did it this way because lockmgr takes so many > parameters which I expect will always be the same; the lock should > always be gotten on behalf of curproc, etc. I just don't want us to end up with lots of foo_lock/unlock functions. It is a bad trend to start. Imagine if each mutex had two such functions associated with it. One slightly cleaner solution might be to create macros read_lock(lock), write_lock(lock) and init_rwlock(lock) that map to lockmgr calls underneath. >> SI_SUB_LOCKS_INIT that initializes lots of locks such as allproc_lock >> and the callout wheel mutex. Also, did you see my lock list document? >> Looks like I need to update it so it can handle lockmgr locks. :-P > > Yeah, I figured you were eating turkey this weekend :) Actually, I was, but I have more to eat on Thursday. :) > I'll write up an entry for the callout_lock if you want. It > locks the callwheel, ticks, softticks and nextsoftcheck. Ok. I guess I should go ahead and commit the first version then. It is in DocBook (looks kind of HTML-ish) but it shouldn't be that hard to pick up. It will end up in doc/en_US.ISO-8859.1/articles/mutex_list/. > You might also want to account for stuff that's not locked, but > is safe by virtue of atomicity. I think astpending falls into this > category since its per-cpu. Yeah. Hmm. That's why I had question marks by astpending and friends. Also, many of the things currently listed as protected by sched_lock may not be in all cases, and many of them shouldn't be protectd by sched_lcok (I think p_stat is one that should, but most of the rest of them shouldn't be.) Getting process stuff locked down alongside of the KSE work is going to be interesting though. :-P -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001120125615.jhb>