From owner-freebsd-smp Mon Nov 20 12:55:51 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 17B4537B479 for ; Mon, 20 Nov 2000 12:55:45 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAKKtgi84155; Mon, 20 Nov 2000 12:55:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001120203045.3DAB8BA7A@io.yi.org> Date: Mon, 20 Nov 2000 12:56:15 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: patch: allproc_lock Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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... >> >> 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 -- 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