From owner-cvs-all Fri Aug 31 0: 0:38 2001 Delivered-To: cvs-all@freebsd.org Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id D48A937B401 for ; Fri, 31 Aug 2001 00:00:30 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4423 invoked from network); 31 Aug 2001 06:57:36 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Aug 2001 06:57:36 -0000 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: Date: Thu, 30 Aug 2001 23:57:42 -0700 (PDT) From: John Baldwin To: Mike Silbersack Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_s Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Matt Dillon 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 31-Aug-01 Mike Silbersack wrote: > > > On Thu, 30 Aug 2001, Matt Dillon wrote: > >> :You could probably minimize a lot of these diffs using a UGAR() macro >> :similar >> :ot BSD/OS's EGAR macro. It unlocks Giant and then returns the value passed >> :in. >> :Thus return(foo); becomes UGAR(foo); >> : >> :This would make the diffs much simpler, which also makes it easier to take >> :Giant out of syscalls later on: >> : >> :#define UGAR(rval) do { \ >> : int _val = (rval); \ >> : mtx_unlock(&Giant); \ >> : return (_val); \ >> :} while (0) >> >> I think it's better to keep it explicit. I don't want to hide the >> fact that I am manipulating Giant. >> >> -Matt > > There could be cases where you'd want to drop Giant earlier than at the > end of the function too, I suppose. (Possibly in cases where you only > need Giant to grab certain pieces of data, then can go on with a more > local mutex.) In these cases though you usually just grab the lock at the top and release at the bottom (or for error returns). > Actually, I guess now would be a good time to ask. Is grabbing Giant late > / dropping it early a problem? I ask because I'm unclear if it's bad to > have a function that's only part Giant-dependant. It's not bad to be part Giant-dependent. You may want to avoid dropping and picking up locks a lot though, it doesn't hurt to just hold the lock across a few extra operations if it avoids a unlock/lock pair. However, the real question is if dropping Giant breaks expected atomicity of the function in question. -- 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 cvs-all" in the body of the message