From owner-freebsd-arch@FreeBSD.ORG Fri Nov 23 16:14:22 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 0799D16A477 for ; Fri, 23 Nov 2007 16:14:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id C041D13C469 for ; Fri, 23 Nov 2007 16:14:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 23 Nov 2007 08:14:21 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 46F49126AB4; Fri, 23 Nov 2007 08:14:20 -0800 (PST) Message-ID: <4746FC5B.3040809@elischer.org> Date: Fri, 23 Nov 2007 08:14:19 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alfred Perlstein 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> In-Reply-To: <20071123082339.GN44563@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , Max Laier , freebsd-arch@freebsd.org, Stephan Uphoff 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 16:14:22 -0000 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. recursion is hard for the caller to know because unrelated code could have done the original calls. The only way it can know is if there is some generic recursion detection. > > -Alfred > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"