From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 03:16:56 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06ABC16A419; Sat, 24 Nov 2007 03:16:56 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0961513C468; Sat, 24 Nov 2007 03:16:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C60901A4D7C; Fri, 23 Nov 2007 19:16:55 -0800 (PST) Date: Fri, 23 Nov 2007 19:16:55 -0800 From: Alfred Perlstein To: Robert Watson Message-ID: <20071124031655.GD71382@elvis.mu.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071123235346.E14018@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Stephan Uphoff , Attilio Rao , freebsd-arch@freebsd.org, Max Laier Subject: Re: rwlocks, correctness over speed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 03:16:56 -0000 * Robert Watson [071123 16:27] wrote: > > 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. Yes that's all well and good, however we have to come to a consensus on whether to bite the bullet and implement recursion tracking on rwlocks or disallow it, because unless we do this, we open the system up to starvation live-lock. So let's make a decision about it instead of just talking about it. -- - Alfred Perlstein