Date: Sat, 24 Nov 2007 14:53:52 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Robert Watson" <rwatson@freebsd.org> Cc: Stephan Uphoff <ups@freebsd.org>, Max Laier <max@love2party.net>, Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. Message-ID: <3bbf2fe10711240553k1eb35a5au23cae8af08f5864c@mail.gmail.com> In-Reply-To: <20071124103231.A14018@fledge.watson.org> References: <20071121222319.GX44563@elvis.mu.org> <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> <200711221726.27108.max@love2party.net> <20071123082339.GN44563@elvis.mu.org> <47469328.8020404@freebsd.org> <20071123092415.GP44563@elvis.mu.org> <4746F858.4070301@freebsd.org> <20071123235346.E14018@fledge.watson.org> <3bbf2fe10711231930m459dc800wbbb894b9fd50ca13@mail.gmail.com> <20071124103231.A14018@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/11/24, Robert Watson <rwatson@freebsd.org>: > On Sat, 24 Nov 2007, Attilio Rao wrote: > > > 2007/11/24, Robert Watson <rwatson@freebsd.org>: > > > >> While I'm no great fan of recursion, the reality is that many of our kernel > >> subsystems are not yet ready to disallow recursion on locks. Take a look > >> at the cases where we explicitly enable recursive acquisition for > >> mutexes--in practice, most network stack mutexes are recursive due to the > >> recursive calling in the network stack. While someday I'd like to think > >> we'll be able to eliminate some of that, but it won't be soon since it > >> requires significant reworking of very complicated code. The current model > >> in which recursion is explicitly enabled only where still required seems to > >> work pretty well for the existing code, although it's hard to say yet in > >> the code I've looked at whether read recursion would be required--the > >> situations I have in mind would require purely write recursion. There's > >> one case in the UNIX domain socket code where we do a locked test and > >> conditional lock/unlock with an rwlock for exclusive locking because > >> recursion isn't currently supported, and that's not a usage I'd like to > >> encourage more of. > > > > Oh, I just didn't notice this -- rwlock are only present in 7.0 and in 7.0 > > they support recursion in exclusive mode, so I'm not sure what do you mean > > with 'recursion isn't currently supported'. > > I must have missed recursion arriving then -- I'll modify uipc_usrreq.c to set > the recursion flag on the rwlock in UNIX domain sockets rather than doing the > nasty hack that was previously required. At the time, the hack was added > because it seemed recursion was not going to be added to rwlocks, but > sonewconn() behavior for listen sockets really ended up requiring it. attilio 2007-06-26 21:31:56 UTC FreeBSD src repository Modified files: sys/kern kern_rwlock.c sys/sys _rwlock.h rwlock.h Log: Introduce a new rwlocks initialization function: rw_init_flags. This is very similar to sx_init_flags: it initializes the rwlock using special flags passed as third argument (RW_DUPOK, RW_NOPROFILE, RW_NOWITNESS, RW_QUIET, RW_RECURSE). Among these, the most important new feature is probabilly that rwlocks can be acquired recursively now (for both shared and exclusive paths). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10711240553k1eb35a5au23cae8af08f5864c>