Date: Sun, 12 Mar 2006 22:28:27 +0800 From: prime <guomingyan@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re:Doubts about PICKUP_GIANT() and mtx_lock(&Giant) Message-ID: <1fa17f810603120628q386d6811t9a2cab36c9cb7a0b@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Date: Sun, 12 Mar 2006 16:25:07 +0530
> From: "Pranav Peshwe" <pranavpeshwe@gmail.com>
> Subject: Doubts about PICKUP_GIANT() and mtx_lock(&Giant).
> To: freebsd-hackers@freebsd.org
> Message-ID:
> <cdfd7d6d0603120255x3039efa2w68c9217f5706e78c@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>
> Hello,
> What is effectively the difference between PICKUP/DROP_GIANT an=
d
> mtx_lock/unlock(&Giant) ? From the macro expansion, i surmise that
> PICKUP/DROP_GIANT deals with recursion in Giant locking.Is this correct ?
> is
> this the only difference ? What will happen if i mix the usage of
> PICKUP/DROP_GIANT and mtx_lock/unlock(&Giant) ?
> Also,is there any hard and fast rule prescribing which method of taking
> the
> Giant should be used where in the kernel ?
>
> TIA.
>
> Regards,
> Pranav
>
>
> -------------------------------------------------------------------------=
--
> To argue with a person who has renounced the use of reason is like
> administering medicine to the dead. -- Thomas Paine
>
> In my opinion,DROP_GIANT() guarantees that Giant is *really*
dropped even it is recursively held.Sometimes we have to make sure
that Giant is not held,and mtx_unlock(&Giant) can't give us such
a promise,so you shouldn't use it in such situations.
Mix the usage of DROP_GIANT() and mtx_unlock(&Giant) is not
a good idea,I think. In fact,if you really do it,even the compiler
will reject your source code :-).
Regards,
MingyanGuo
--
Three passions, simple but overwhelmingly strong, have governed my life:
the longing for love, the search for knowledge, and unbearable pity for
the suffering of mankind.
---------Bertrand Russell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1fa17f810603120628q386d6811t9a2cab36c9cb7a0b>