Date: Fri, 23 Nov 2007 08:45:49 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Stephan Uphoff <ups@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, Max Laier <max@love2party.net>, freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. Message-ID: <20071123164549.GR44563@elvis.mu.org> In-Reply-To: <4746F858.4070301@freebsd.org> References: <20071121222319.GX44563@elvis.mu.org> <200711221641.02484.max@love2party.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
* Stephan Uphoff <ups@freebsd.org> [071123 07:57] wrote: > Alfred Perlstein wrote: > > > >That's an interesting hack, I guess it could be done. > > > >I would still like to disallow recursion. > > > Oh - I am all for disallowing recursion. > In my opinion the only valid place for a thread to acquire the same lock > multiple times is inside a transaction system with full deadlock detection. > The question is if we can do that this late in the game? > Maybe we could make non recursive the default and add a call > rw_allow_recurse or rw_init_recurse to allow recursion on a lock if we > can't get away with > the straight out removal of the option? (Or less desirable - keep the > current default and add functions to disallow recursion) > >Can we come to a concensus on that? > > > > > > +1 for disallowing recursion > > Stephan The plan is to simply mention in the documentation that it's not allowed, we'll also remove any options associated with read recursion (if there are any). INVARIANTS to catch such things, and subsystems that still use it will be allowed to live for a while until they are fixed. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071123164549.GR44563>