Date: Mon, 20 Nov 2000 20:15:12 -0800 From: Jake Burkholder <jburkhol@home.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: smp@FreeBSD.ORG Subject: Re: patch: allproc_lock Message-ID: <20001121041512.B3BADBA7A@io.yi.org> In-Reply-To: Message from John Baldwin <jhb@FreeBSD.ORG> of "Mon, 20 Nov 2000 12:56:15 PST." <XFMail.001120125615.jhb@FreeBSD.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. Yeah, ok. I think I'll just use lockmgr explicitly. Its possible that in some cases we'll want to use the interlock in the future. > > >> 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/. Yeah, please commit it. I'm vaguely familiar with docbook, I'm sure I can figure it out. > > > 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.) This needs careful review, but of course it'll all change with KSEs :) > > Getting process stuff locked down alongside of the KSE work is going to be > interesting though. :-P > Yeah, I don't know how this is going to work. Based on how long it took to get smpng off the ground, and the state that its in now, it seems nuts to me to try to get both these things done and well tested before 5.0 goes out, but I guess we'll see. > -- > > 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 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?20001121041512.B3BADBA7A>