Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Aug 2001 23:57:42 -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.010830235742.jhb@FreeBSD.org>
In-Reply-To: <Pine.BSF.4.30.0108302159470.19462-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:
> 
>> :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 <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.010830235742.jhb>