From owner-freebsd-arch@FreeBSD.ORG Fri Nov 23 09:24:20 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 507F616A47B; Fri, 23 Nov 2007 09:24:20 +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 2A01613C465; Fri, 23 Nov 2007 09:24:19 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 91B901A4D7E; Fri, 23 Nov 2007 01:24:15 -0800 (PST) Date: Fri, 23 Nov 2007 01:24:15 -0800 From: Alfred Perlstein To: Stephan Uphoff Message-ID: <20071123092415.GP44563@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47469328.8020404@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Attilio Rao , Max Laier , freebsd-arch@freebsd.org 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: Fri, 23 Nov 2007 09:24:20 -0000 * Stephan Uphoff [071123 00:46] wrote: > Alfred Perlstein wrote: > >* Max Laier [071122 14:40] wrote: > > > >>On Thursday 22 November 2007, Attilio Rao wrote: > >> > >>>2007/11/22, Max Laier : > >>> > >>>>rwlocks are already used in places that do recursive reads. The one > >>>>place I'm certain about is pfil(9) and we need a proper sollution for > >>>>this. Before rwlocks were used, I had a handrolled locking that > >>>>supported both read/write semantics and starvation avoidance - at the > >>>>cost of failing to allow futher read access when a writer asked for > >>>>access. This however, was quite application specific and not the > >>>>most efficient implementation either. > >>>> > >>>I'm not a pfil(9) expert, but for what I've heard, rmlocks should be > >>>really good for it, shouldn't them? > >>> > >>>The concept is that if we want to maintain fast paths for rwlock we > >>>cannot do too much tricks there. And you can really deadlock if you > >>>allow recursion on readers... > >>> > >>How about adding rwlock_try_rlock() which would do the following: > >> 1) Only variant to allow[1] read recursion and ... > >> 2) ... only if no outstanding write requests > >> 3) Let the caller deal with failure > >> > >>This can be implemented statically, so no overhead in the fast path. The > >>caller is in the best position to decide if it is recursing or not - > >>could keep that info on the stack - and can either fail[2] or do a normal > >>rwlock_rlock() which would wait for the writer to enter and exit. > >> > >>[2] In most situation where you use read locks you can fail or roll back > >>carefully as you didn't change anything - obviously. In pfil - for > >>instance - we just dropped the packet if there was a writer waiting. > >> > >>[1] "allow" in terms of WITNESS - if that can be done. > >> > > > >The problem is that there is no tracking in the common case (without > >additional overhead), so you can't know if you're recursing, unless > >you track it yourself. > > > >-Alfred > > > > > > > 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. > > Stephan That's an interesting hack, I guess it could be done. I would still like to disallow recursion. Can we come to a concensus on that? -- - Alfred Perlstein