Date: Sat, 24 Nov 2007 01:35:33 +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: <3bbf2fe10711231635i72df8babucedd1e5bdef7175d@mail.gmail.com> In-Reply-To: <20071123235346.E14018@fledge.watson.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> <20071123235346.E14018@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/11/24, Robert Watson <rwatson@freebsd.org>: > > On Fri, 23 Nov 2007, Stephan Uphoff wrote: > > >>> I talked with Attilio about that on IRC. Most common cases of writer > >>> starvation (but not all) could be solved by keeping a per thread count of > >>> shared acquired rwlocks. If a rwlock is currently locked as shared/read > >>> AND a thread is blocked on it to lock it exclusively/write - then new > >>> shared/read locks will only be granted to thread that already has a shared > >>> lock. (per thread shared counter is non zero) > >>> > >>> To be honest I am a bit twitchy about a lock without priority propagation > >>> - especially since in FreeBSD threads run with user priority in kernel > >>> space and can get preempted. > >> > >> 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) > > 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. I think however that Stephan is just referring to the readers recursion (as we are doing) that if present should be just in few points. If we want todo a radical switch of this genre this is the right moment, just before rwlock became too widespread. I have a patch against witness which would check for readers recursion and panic, I will post in the night or tomorrow. 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?3bbf2fe10711231635i72df8babucedd1e5bdef7175d>