Date: Wed, 29 Jul 2009 08:02:27 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Randall Stewart <rrs@lakerest.net> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: svn commit: r195918 - head/sys/netinet Message-ID: <alpine.BSF.2.00.0907290735170.17344@fledge.watson.org> In-Reply-To: <354E0657-DC37-4493-8E17-D09B257B5A28@lakerest.net> References: <200907281409.n6SE971u034585@svn.freebsd.org> <20090729051016.GB3550@garage.freebsd.pl> <354E0657-DC37-4493-8E17-D09B257B5A28@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Jul 2009, Randall Stewart wrote:
>> Instead of using additional argument to the sctp_add_to_readq() function,
>> wouldn't it be sufficient to just check with mtx_owned(9) if the lock is
>> already held?
>
> Hmm... I suppose one could go that way... but traditionally upper code as
> told the lower code that it holds/does not hold the lock. This is true in
> quite a few other functions...
Structures of the form:
if (mtx_owned(&mtx))
mtx_unlock(&mtx);
Strike me as less robust than code with either fixed assertions about lock
state from the caller, or code that accepts a flag that in effect leads to two
variants each with fixed state that can be asserted. I.e.,
void
foo(void *obj)
{
OBJ_LOCK_ASSERT(obj);
...
}
or:
void
foo(void *obj, int arg_locked)
{
if (arg_locked)
OBJ_LOCK_ASSERT(obj);
else
OBJ_LOCK(obj);
...
if (!arg_locked)
OBJ_UNLOCK(obj);
}
I guess I'm sort of OK with structure but it smacks of poor code design:
void
foo(void *obj)
{
int locked;
if (OBJ_LOCK_OWNED(obj)) {
locked = 1;
OBJ_LOCK(obj);
} else
locked = 0;
...
if (locked)
OBJ_UNLOCK(obj);
}
However, this structure doesn't lend itself to moving to lock types that can't
cheaply support mtx_owned()-like operations, such as read acquisitions of
reader-writer locks.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0907290735170.17344>