From owner-cvs-all Thu Aug 30 22:20:53 2001 Delivered-To: cvs-all@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 30B4D37B403 for ; Thu, 30 Aug 2001 22:20:47 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 81289 invoked by uid 3193); 31 Aug 2001 03:25:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Aug 2001 03:25:07 -0000 Date: Thu, 30 Aug 2001 23:25:07 -0400 (EDT) From: Mike Silbersack X-Sender: To: Matt Dillon Cc: John Baldwin , , Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_sem.c In-Reply-To: <200108310230.f7V2Uis61771@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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.) 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? 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.) I think that if a mini-faq on such things could be written, many people could start protecting things from the bottom up. In some cases, (like arc4random's), protecting it with a mutex won't be important for a while (until the tcp stack is threaded.) However, since threading things from the bottom up should be relatively easy, it might be worthwhile for us smp newbies to start with it while the more experienced do the heavy lifting from the top down. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message