Date: Thu, 30 Aug 2001 23:57:43 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Mike Silbersack <silby@silby.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com> Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_s Message-ID: <XFMail.010830235743.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.30.0108302309010.75391-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31-Aug-01 Mike Silbersack wrote: > > On Thu, 30 Aug 2001, Matt Dillon wrote: > >> As long as you aren't holding any other mutexes when you aquire Giant >> and the stuff outside of Giant is MP-SAFE, and there are no atomicy >> constraints between the Giant-locked sections making up the syscall, >> and you are holding a reference on structural objects you hold through a >> loss of Giant (and you are holding references on objects held if you >> block while holding Giant)... then you can obtain and drop Giant >> all you want. > > Ok, good. I just wanted to make sure there weren't any unstated rules > with regard to this. > > Also, just for clarification, Giant can be grabbed recursively, correct? > Our "SMP kernel synchronization rules" pages seems to imply so, but isn't > too clear. > > (http://people.freebsd.org/~jasone/smp/smp_synch_rules.html, for > reference.) That does need some clarification. I'm working on a paper for BSDCon that details locking for this stuff. When its done it will be in the developer's handbook as well. > Also, on that page it states: > > Do not tsleep()/msleep()/cv_wait() while holding a mutex other than Giant. > > Is this still true? With this restriction, threading sounds like it could > be very tough. Might it be possible to double-check that page (it is > almost a year old now) and add information which could be useful to others > pushing down locks? Not really. spl's didn't stay across sleep's either. The only data 4.x locks across a sleep is via lockmgr(). You do the same now with sx locks. Mutexes are more replacements for spl() type functionality, except that spl's only protected against interrupts, and were more coarsely grained. > I suppose some of this info could be picked up from a good book on SMP > strategies, but I think a quick faq could be very helpful. > > Right now I'm thinking of protecting arc4random (it's not important, but > I've been in it recently, and it's a very simple piece of code - one entry > point.) However, just thinking about it I've already come up with a few > questions: > > 1. Do I need to grab Giant before calling down to the time functions? > 2. Do I need to grab Giant before calling into the random device? (I > suspect not, since Mark wrote it recently.) First off, don't drop Giant if you are called with it as you may break assumptions in the code that calls you. Secondly, Giant always has to be first in lock orders, so don't grab Giant if you are holding any other locks or you will break things. As a good rule of thumb for now, don't worry about Giant. If some of the code you call uses it, add mtx_assert()'s to ensure calling code holds Giant when it calls you to avoid lock order problems with Giant. -- 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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010830235743.jhb>