Date: Wed, 29 Jul 2009 07:30:56 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Randall Stewart <rrs@lakerest.net> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r195918 - head/sys/netinet Message-ID: <20090729053056.GC3550@garage.freebsd.pl> 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
--qjNfmADvan18RZcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2009 at 01:23:24AM -0400, 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? >=20 > Hmm... I suppose one could go that way... but traditionally upper code = =20 > as > told the lower code that it holds/does not hold the lock. This is true > in quite a few other functions... We can find examples of both behaviours in many places, that's true. The reason to keep additional argument is that once you decide to move to read-write locks it might not be reliable to check if read-lock is already held by the current thread. All in all both solutions work, my observation was only that diff could be significantly reduced by using mtx_owned(9), nothing major. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qjNfmADvan18RZcF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKb96QForvXbEpPzQRAojyAJ9tCSLHEaovLIDI5QylnxwIl0VKvACg+Cty AG6WF5UCdcAEE6i+01J2NSs= =q126 -----END PGP SIGNATURE----- --qjNfmADvan18RZcF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090729053056.GC3550>